Re: Deprecate fltk graphics toolkit?

[Daniel J Sebald]

On 11/08/2017 06:25 AM, Pantxo wrote:
> John W. Eaton wrote
> > As I understand it, there are some issues with starting Qt graphics when
> > running in non-gui mode, and that the fltk graphics toolkit does not
> > have those problems.  But if we could fix that, and make the Qt plot
> > window work when running in --no-gui mode, could we deprecate the fltk
> > graphics toolkit?
> >
> > It seems wasteful to have to maintain both Qt and fltk graphics.  For
> > example, I just made a change for the "Save" and "Save As" menu items in
> > the Qt graphics code.  This change took much longer than it should have
> > when I remembered that the change would also need to be made in the fltk
> > graphics code and that needed to be done in a completely different way.
> >
> > Comments?
> >
> > jwe
>
> I am in favor of removing FLTK but first we should ensure we have a way to
> run Octave interpreter and Qt figures in the same thread, which is currently
> not possible. The main reason is that comparing FLTK and Qt is currently the
> best way to determine wether a graphics bug is due to thread management or
> to core opengl code. Basically "octave --no-gui" would be single-threaded
> "octave" would be multi-threaded.

I think the issue there is that Qt graphics has to be run in the main 
thread.  So the --no-gui option (different from octave-cli) is a means 
to get Qt graphics support in the main thread.  But you are right. 
Perhaps the code could be configured so that compiling the octave-cli 
version puts everything in a single thread.  Then there'd be no need for 
the --no-gui option anymore.  The Qt graphics/GUI variation would still 
have the worker-process paradigm.  Is there an advantage to that?


> That would also raise the question wether we want to continue using readline
> event loop (callback based mechanism) for Qt figures->interpreter
> communication or make a transition to use Qt event loop (signal/slot
> mechanism).

You are asking the right questions.  I did a prototype years ago that 
removed the callback approach.  It used signal/slot on the GUI side of 
things, but without Qt code in Octave core proper.  (In my view, it 
would be a mistake to integrate any Qt code into the core.)  Basically, 
on the Qt GUI side of things it looked like a signal/slot mechanism for 
issuing commands and getting results.  On the core side of things it 
looked like a simple passageway where all data travels, very similar to 
the already existing queuing system for user-input octave commands.  Not 
worth going into details, but suffice it to say I felt then and now that 
this was/is an important design issue.

Dan