Re: Removing __init_qt__ dependency on libgui

[John W. Eaton]

On 11/17/20 1:14 PM, Alex Leach wrote:

> *From:* John W. Eaton <jwe@octave.org>

>     But before we go too far discussing details, I'd like to agree on the
>     goals.  How do you want to use the Octave graphics code?  I imagine that
>
>         octave::interpreter octave_interpreter (...);
>         QOctaveGraphics *graphics_widget
>           = new QOctaveGraphics (parent_qt_widget, octave_interpreter);
>
>     where you create the graphics widget that is linked to your already
>     initialized embedded Octave interpreter or perhaps
>
>         QOctaveGraphics *graphics_widget
>           = new QOctaveGraphics (parent_qt_widget);
>
>     and the QOctaveGraphics widget will initialize it's own interpreter
>     object would be reasonable.  However, due to global variable usage in
>     the interpreter, only one Octave interpreter is allowed in a given
>     process so only one graphics object could be created this way.
>
>
> I think either should work fine, but the second case might be easier, as 
> the GUI and the interpreter need to run in separate threads, especially 
> for long running scripts.

We will probably need some variation of the first for using it with the 
Octave GUI, where the interpreter (or interpreter running in a separate 
thread) will already exist.

> My current effort is to create a subclass of QApplication and another of 
> QMainWindow. The Application launches a separate worker thread and it's 
> this that runs the interpreter. The MainWindow and its child widgets 
> emit signals which effectively call octave functions indirectly, through 
> the worker thread:-
>
> public slots:
> octave_value_list call_octave_fcn( const QString &fcn_name, 
> octave_value_list args );
>
> Then, a couple of signals for sending status updates and the end result > back:-
>
> void status_update( const SomeStatusEnum &status);
> void send_results( octave_value_list retval );
>
> But this is all interacting with the interpreter of course, not the 
> plots or figure window.

OK.  If the Octave interpreter were also packaged as a Qt object with 
public signals and slots, what set of signals and slots do we need?

Currently, the GUI has some signals that it can emit to invoke Octave 
functions or, using C++ lambda expressions, run arbitrary code inside 
the interpreter thread.  Those lambda expressions can then emit Qt 
signals directly rather than using the octave event manager class.

As you mentioned earlier, it would be good to simplify the event manager 
object.

> The other thing that I've already hinted at, which would be nice for 
> consistency purposes in my Qt / C++ app: I launch QFileDialog windows to 
> select files and/or folders (these are what go into my 'args' for the 
> call to octave). When the figure windows are shown by the Octave script, 
> it would be nice if when clicking Save As, I'd have Qt dialogs show, 
> instead of the ftlk ones. Seems a bit odd having two kinds of file 
> dialog within a single app: Qt dialogs for my code, fltk for the Octave 
> scripts.

I'm not sure where fltk dialogs are coming from?  It should be possible 
for them to all be based on Qt widgets.

jwe