octave-maintainers
[Top][All Lists]
Advanced

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

Removing __init_qt__ dependency on libgui


From: Alex Leach
Subject: Removing __init_qt__ dependency on libgui
Date: Wed, 11 Nov 2020 10:22:17 +0000

Hello,

I have been attempting to write a small C++ / Qt application that can interpret Octave scripts and plot figures, using the qt backend. This has been much more difficult than I'd hoped, and I've spent quite a lot of time trying to figure out why the qt backend isn't available to a qt application linked to the octave libraries.

The Qt backend seems to have been originally derived from the QtHandles github repository at https://github.com/goffioul/QtHandles/, with the source code from this repo copied into Octave's libgui/graphics/. Originally, and in the current 5.2.0 release, this was compiled as a standalone module: __init_qt__.oct, but qt figures couldn't easily (at all?) be launched outside of the main GUI.

In the last couple of months however, some of the most recent commits have completely removed compilation of a separate __init_qt__.oct module and compiled this code directly into the main Octave GUI library, as quite rightly, it couldn't be loaded outside of the main GUI anyway.

I would like to propose however, that development of the qt backend go back the other way. Instead of merging and increasing its dependencies on the core GUI, can we try and bring back its modular nature and remove any dependencies on the main GUI?

When the QtHandles was originally developed, it appears there was a very simple tool that would launch the Octave interpreter, and allow launching of the Qt backend:-

https://github.com/goffioul/QtHandles/blob/master/tool/octave-qt.cpp

This is exactly the sort of thing I'm looking to try and implement, so may I propose that __init_qt__.oct comes back and the module becomes completely decoupled from the main GUI?

Some initial suggestions which may help make this happen (referring to github commit hashes; sorry if hg ones would be easier to follow!):-
  • 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.
  • Would obviously need to revert the commit that stopped compiling a separate module (5dcc746).
  • 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?
  • libgui/graphics/__init_qt__.cc. In release 5.2.0, there was a PKG_ADD line that tests for __octave_link_enabled__(). Without a global instance of octave_link, the module won't load at all. No warning is produced, so this took me a while to figure out. Now the test shows __event_manager_enabled__. Can any of these requirements either be removed, or just get the qt handles module to initialise these things itself?
I don't think there's a huge amount else to do, but that's probably easier said than done!

As the Octave maintainers, would you be interested in seeing the qt handles backend completely decoupled from the main GUI and made strictly modular again?

Kind regards,
Alex

reply via email to

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