Re: Deprecate fltk graphics toolkit?

[Daniel J Sebald]

On 11/08/2017 12:15 PM, John W. Eaton wrote:
> On 11/08/2017 12:50 PM, Daniel J Sebald wrote:
>
> > 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.
>
> Qt graphics needs the Qt event loop.  The original QtHandles code 
> managed this somehow, because it was implemented as an add-on to Octave 
> before Octave had a GUI based on Qt.  So it must be possible to use a 
> Qt-based graphics widget from Octave that does not have a GUI running 
> initially.

That would be one way to go, i.e., to run the plotting graphics separate 
from the GUI graphics.  I would have to guess, thought, that this 
QtHandles had to have an event loop and main thread.  Was it a separate 
process that somehow interacted?  Still, it might be best to keep the 
plotting graphics in the same process and thread as the GUI graphics. 
This is a design issue to think about.


> > 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.
>
> I think we'd still want a --no-gui option to avoid starting the GUI.
>
> Some people will still want a minimal version of Octave that doesn't 
> directly link to Qt libraries.  And it would be nice to be able to start 
> and stop the GUI from the command line, same as Matlab can do.  If we 
> could do that (dynamically load the GUI instead of linking it directly 
> to the main program), then we wouldn't need octave-cli.

Remember, though, that Octave-GUI is using the model of Octave core 
running in a worker thread.  That's a pretty common model for Qt design. 
 What happens when someone launches Matlab from the command line in 
non-GUI mode and then calls "gui"?  Do both the shell command line and 
terminal inside the GUI accept input?  That would seem strange.  Does 
the shell command line just freeze until the GUI is exited?  That would 
be my guess because I'm recalling Matlab being able to launch its own 
user-designed GUI's which behave that way.

The command-line octave in its own process/main-thread would have to 
somehow move to the GUI's worker thread.  Maybe it is possible to do 
that somehow in Qt; I never investigated.  One other thing might be 
possible is to launch the GUI version of Octave and then somehow 
transfer all the variables and history from the shell Octave-core into 
the worker-process Octave-core.  It would look right, but I'm not sure I 
like that approach.

Dan