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

[Alex Leach]

> -----Original Message-----
> From: Kai Torben Ohlhus <k.ohlhus@gmail.com>
> Sent: 19 October 2020 06:51
> To: Alex Leach <zander_leach@hotmail.com>
> Cc: help-octave@gnu.org
> Subject: Re: QtHandles in a C++ application with embedded interpreter
> 
> On 10/16/20 6:53 PM, Alex Leach wrote:
> 
> Hello Alex,
> 
> Your project sounds interesting, but there is the danger of reinventing the
> wheel:
> 
> > write a Qt app that has an embedded interpreter.
> 

Dear Kai,

Many thanks for the response. Haha, yes sometimes I fear I need to do the same, 
and that is exactly what I'm trying to avoid! The shared libraries and headers 
are there, though, I think, if I can call into them correctly.

> 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?

Essentially, what I'm trying to do, is port a MatLab application ('.mlapp') 
file to Octave. My colleagues, the end-users are not computer savvy at all, and 
have been shown how to use this mlapp only. The app has four tabs, in each of 
which a few parameters can be set, a file, folder or both can be selected and 
then when pressing the Run button, a .m function file is called with a  set of 
parameters.

The plots don't need to be re-computed after parameters are tuned or 
manipulated. Well, the functions can be re-run of course, but it will re-run 
the code from the beginning, as opposed to dynamically updating the figures etc.

When embarking on this approach, I did find the uicontrols page you provided, 
but to be honest I thought it would be more complicated doing it that way, I 
just wanted to redraw the mlapp in Qt Designer and then call the .m files, as 
per the embedded.cc example you showed. Seemed simple enough I thought!

> 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).

Oh dear, that does sound like I've gone in the wrong direction for this 
project! Well, the embedded Octave I've got does show and launch figures okay, 
it's just that it shows them with the fltk backend, whereas the qt backend is 
much prettier(!), and perhaps easier to use, too.

I don't know what's going on with the '__init_qt__' function. It's not throwing 
an error and there's no output shown on stdout or stderr. Calling it from 
Octave-cli.exe shows 'error: __init_qt__: QApplication object must exist.', so 
I don't know exactly why in my app, it isn't registering the backend properly.

So, the GUI I've got does work actually quite well, it's just I'd prefer it 
used the Qt backend. I was hoping by staying within the realms of Qt, I might 
be able to reduce the number of DLLs and libraries required when redistributing 
this app with my colleagues.
 
> 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].

Oh, thanks, I hadn't seen that bug report. I was also getting seg-faults for a 
while, but I've found it very hard to track down seg-faults in Octave, as I've 
been unsuccessful compiling Octave from source (with debug symbols) on Msys for 
windows. A bit off topic that, however.

I will put together a minimal example and upload to my github account. I'll 
send a link shortly. I don't think it actually needs any widgets to demonstrate 
what I'm trying to do, just a sub-class of octave::application and 
octave::interpreter. The latter I did perhaps unnecessarily, so that I can also 
subclass QObject and pass it to a worker QThread, and then all .m files are 
called from the same thread. That's how I've gone about multi-threading, I 
haven't bothered with mutexes and locks, like octave_link provides. But it does 
mean that .m code is completely blocking and un-cancellable!

Thanks and Kind regards,
Alex