octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing __init_qt__ dependency on libgui


From: Alex Leach
Subject: Re: Removing __init_qt__ dependency on libgui
Date: Tue, 17 Nov 2020 18:14:36 +0000



From: John W. Eaton <jwe@octave.org>
Sent: 17 November 2020 16:34
To: Alex Leach <zander_leach@hotmail.com>; octave-maintainers@gnu.org <octave-maintainers@gnu.org>
Subject: Re: Removing __init_qt__ dependency on libgui
 
OK.  My goals for the Qt graphics code in Octave was focused mostly on
getting it to work better in the context of the Octave GUI and I wanted
to eliminate the global access to the interpreter and GUI objects.
Okay. I guess eliminating global access to the interpreter allows for multiple interpreters? And eliminating global access to GUI objects sounds like my goal? Is there anywhere in particular you have in mind, where the Qt graphics code doesn't work well with the Octave GUI?

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. Initially, I was just trying to embed an interpreter without creating separate threads, and using the very simple example documentation at https://octave.org/doc/v5.2.0/Standalone-Programs.html as inspiration. I then realised I had long running scripts and needed a separate worker thread for the interpreter. Further, separate threads allows a progress bar to be updated, which is nice.

Is that the kind of thing you would like to do?  If so, how would you
interact with this object?  Would you use interpreter functions to
create plots or would you use Qt signals to pass data and plot options
to the graphics widget?

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. Personally, I have no need to control the figures directly from C++. I have some long-running .m files that plot their data at the end on various sub-plots, and it's these that I'd like shown on the Qt backend.

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.

On that note, I found out the hard way why __get_funcname__.m tests for __event_manager_enabled__. The uigetdir/uigetfile, etc. functions in __init_qt__.cc need to call QFileDialog static functions from the GUI thread, which they don't do without the event manager. Nice seg-fault if you try using them without an event manager. I came up with a work-around that doesn't require the event manager, but I'm sure this could be improved upon.

Hope that answers some of your questions anyway, and is constructive in the right direction! Do you think there are any major obstacles to implementing this?

Kind regards,
Alex

reply via email to

[Prev in Thread] Current Thread [Next in Thread]