Re: Qt help w/bug #45943

[Torsten]

On 15.08.2018 20:47, Daniel J Sebald wrote:
> On 08/15/2018 11:57 AM, Rik wrote:
>> Could someone who is familiar with Qt take a look at
>> https://savannah.gnu.org/bugs/?45943?
>>
>> The issue is that Octave needs a way to select a window and raise it the
>> top of the stack.  It appears that simply calling activateWindow()
>> followed
>> by raise() would work.  See
>>
>> http://doc.qt.io/archives/qt-4.8/qwidget.html#activateWindow
>> http://doc.qt.io/archives/qt-4.8/qwidget.html#raise
>>
>> However, I'm not the right person to code this.  If this sequence of
>> function calls works then it could be placed into a function that the
>> main
>> interpreter thread could reach so that shg will work.  I suppose this
>> means
>> going through octave_link.
> 
> The Qt commands are about right; there are examples of raising windows
> elsewhere in the GUI, so just grep for those Qt functions
> "activateWindow", etc.
> 
> It's the last sentence where all the work is, and the philosophical
> aspect of it is that there is a new function added which flows from the
> core to the GUI.  It's an entanglement of the two entities, when it
> would be nice to keep things separate.  I've imagined from the beginning
> an OOP-like scheme in which the GUI programmer could install their own
> overriding function, yet still have access to the previous function in
> some kind of "function stack"...just like what can be done with C++, e.g.,
> 
>   class2::foo ()
>   {
>     class1::foo ();
>     if (foovar == 2)
>     {
>        std::out << "Worked!";
>     }
>   }
> 
> It shouldn't be a difficult thing to do because already Octave is set up
> to resolve the source file from search paths.  Perhaps a short stack of
> functions, for which the GUI has a C-callable routine
> 
>     void (*overridefunc)();
> 
>     overridefunc = &qt_shg;
>     install_command_line_function("shg", overridefunc);
>     overridefunc = &qt_dbstep;
>     install_command_line_function("dbstep", overridefunc);
>     overridefunc = &qt_dbstop;
>     install_command_line_function("dbstop", overridefunc);
>     etc.
> 
> (could use a table of function pointers and a loop).  Or maybe it would
> make sense for install_command_line_function() to be a script command
> that could be done after launch.
> 
> In any case, the OOP gist of it would be that after calling one of the
> above, the "function name stack" might be:
> 
>     qt_shg
>     default_shg
> 
>     qt_dbstep
>     default_dbstep
> 
>     qt_foo
>     some_script_file_in_path_foo
>     default_foo
> 
> Then the GUI's construct for implementing the routine would be, for
> example,
> 
>   qt_dbstop ()
>     {
>       octave_value result;
>       call_previous_function_in_stack ("dbstep");
>       result = call_background_function ("dbwhere");
> 
>       update_the_yellow_pointer_in_editor (rslt.filename, rslt.linenumber);
>     }
> 
> The point is that the GUI is then customizing these routines the way it
> likes without there having to be any core-programmer knowledge of what
> lies in GUI-land or how to communicate that information to the GUI. Does
> it seem a feasible concept?  Would it end up being more work than it is
> worth?  I don't know.  It just seems to me that with Octave being an
> interpreted language that there are a lot of compiler and OS concepts
> that apply to the interpreter.  Something like the above would make a
> good GSOCL project.
> 
> Another GSOCL project could be an internal "execution stack" and
> "execution variables" so that the octave_quit() of
> 
>   for (int i=0; i < bignumber; i++)
>     {
>       do_some_processing();
>       octave_quit();
>     }
> 
> could be eliminated.  octave_quit() is a difficult thing to remember to
> toss into long routines.  A more elegant approach is to have the signal
> handler for cntrl-C unwind the execution stack, discard the execution
> variables (without moving them from execution memory to global memory)
> and move the execution pointer back to the command line.  Stack
> management is so-so difficulty, heap management high difficulty.  Would
> be an impressive resume item for someone.
> 

Dan, as far as I understand your concept, it is meant for calling core
functions from the GUI thread. Or am I missing something? Bug #45943
requires the other way round.

Torsten