Re: Qt help w/bug #45943

[Daniel J Sebald]

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