Re: QtHandles in a C++ application with embedded interpreter

[Kai Torben Ohlhus]

On 10/16/20 6:53 PM, Alex Leach wrote:
> Hello,
> 
> I'm trying to build what I thought would be a fairly simple Qt
> Application, that calls a few .M script files. When running these
> scripts through the Octave GUI, figures are shown with the lovely
> QtHandles backend. However, I'm struggling to get figures to plot using
> the Qt Handles backend using my own app.
> 
> After realising that the Octave GUI is built with Qt, I thought it would
> be simple to write a Qt app that has an embedded interpreter. As my app
> is built with Qt in C++, the Qt core libraries are all linked in, I'm
> also linking to -loctave -loctinterp -loctgui. Is it possible then, to
> get figures to display using QtHandles in my app?
> 
> I have created a MyApplication class, that subclasses both QApplication
> and octave::application. This therefore has a pointer to an Octave
> interpreter, m_interpreter, with which I can run
> `m_interpreter->eval_string` or `octave::feval` to run code that's
> shipped with my app.
> 
> The last thing I've tried, is to run
> `m_interpreter->eval_string('__init_qt__', false, status)`, but this
> doesn't provide any output on the terminal and if I then list the
> available toolkits (I have a method printBackends, below), it only shows
> 'fltk' and 'gnuplot'. The qt backend is still not available. I've got a
> registerBackends method as well (see below), but this approach doesn't
> seem to work, causing seg-faults later on.
> 
> I've looked at the code in __init_qt__.cc, but without copying
> everything from libgui/graphics and building that with my app, I'm not
> sure how I can call into it? The headers aren't distributed with
> pre-built binaries, and I get linker errors if I try and call
> `F__init_qt__`, after defining it as per the DEFMETHOD_DLD(__init_qt__)
> macro:-
> 
> [snip]
> 



Hello Alex,

Your project sounds interesting, but there is the danger of reinventing
the wheel:

> write a Qt app that has an embedded interpreter.

That seems to be the exact definition of the GNU Octave GUI, where the
inter-thread communication between both players still gives some
developers headaches today.  Thus rather writing a "second GUI for
Octave", what is wrong with the "first" Octave GUI?

If I understand you right, you want to create advanced plots [1,2] with
widgets to tune/manipulate parameters, recompute portions, and get
feedback of the new computed values in a plot, right?  Putting the focus
here, to get things working the way you need them, is not sufficient for
your project?  Can you explain in more detail (code) what went wrong
with your first approach?

If you are still convinced your second approach is worth the effort, you
are the avant-garde on this field (embedding Octave for plotting,
embedding Octave for computing is way easier) and I am afraid you will
have to find out a lot by yourself, just like the original GUI
designers, who worked on it for years!  In this case, can you provide a
more complete example of your work?  From the snippets it is hard to get
a full picture of what you are doing and what might go wrong (best a
link to your repository with a short description how to run it).

Another interesting tutorial is embedded.cc [3], but there is a bug
about it, maybe you should wait for the resolution to integrate it to
your code [4].

HTH,
Kai

[1] https://octave.org/doc/v5.2.0/GUI-Development.html
[2] https://wiki.octave.org/Uicontrols
[3]
https://hg.savannah.gnu.org/hgweb/octave/file/0089f0213384/examples/code/embedded.cc
[4] https://savannah.gnu.org/bugs/?59228