Re: Removing __init_qt__ dependency on libgui

[John W. Eaton]

On 11/11/20 5:22 AM, Alex Leach wrote:

>   * Some recent commits would need to be reverted: 1a9f05b and bca8e11.
>     These aimed to 'eliminate global access to Octave resources in qt
>     graphics classes', but in the process added a base_qobject argument
>     to many class initialisers all over the qt graphics source code.

Looking at this now, I see that the base_qobject object is just used for 
access to the resource manager (see additional comments about that below).

The interpreter object is primarily used to access the gh_manager mutex 
object.  I don't think locking is really handled correctly now.  Fixing 
that might completely avoid the need for direct access to the gh_manager 
mutex in the graphics code.  Or, if we do decide that the right way is 
to lock the gh_manager object in the Qt graphics thread, then maybe we 
could come up with a better way to do that?

Other than locking, the gh_manager object is also used to get 
graphics_object objects.  Are there better ways of doing that job?  Can 
we just emit signals that request something and then respond to a signal 
that comes back from the interpreter?  Or in some instances do we need 
to suspend execution and wait for the result before allowing the 
graphics thread to continue processing?  For example, similar to the 
interpreter_event signals that we have, maybe we could use something like

  emit gh_manager_event ([=] (gh_manager& gh_mgr) { ... });

and have the gh_manager_event processed by the qt_graphics_toolkit 
object (same as the interpreter_event) and at that point we could access 
the gh_manager object without needing to pass it around to all the 
sub-objects that make up the Qt graphics widget.

Whatever we do, we need thread-safe access to the graphics objects that 
are stored in the gh_manager in the interpreter thread and I don't think 
that has ever been done 100% correctly.

The interpreter is also used to get access to the event manager object, 
but that only happens in qt-graphics-toolkit.cc.  We probably don't need 
to worry about the direct access to the interpreter in that file.  For 
the rest.

>   * Any references to the GUI's resource manager need to be removed. I
>     think there are only a couple, used to get mouse and toolbar icons
>     (Canvas.cc and ToolBarButton.cc, respectively), and a window
>     position (annotation-dialog.cc). Are the mouse icons used by the GUI
>     elsewhere? Maybe these icons can be moved into a
>     libgui/graphics/icons/ folder, if they're only used by qthandles
>     figures? Is there any reason libgui/graphics can't have its own
>     resource file?

I assume we'd like to have one configuration dialog for the Octave GUI 
that also allows setting of these resources?  Can that configuration 
dialog use two separate resource files?  If the graphics widget may also 
be used separately, does it need a separate configuration editor?

jwe