Qt help w/bug #45943

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Qt help w/bug #45943

Rik-4
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.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Qt help w/bug #45943

Daniel 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

Reply | Threaded
Open this post in threaded view
|

Re: Qt help w/bug #45943

Torsten-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Qt help w/bug #45943

Daniel Sebald
On 08/15/2018 02:26 PM, Torsten wrote:

> 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

I meant the other way around.  You're right that calling core functions
(and getting the information back from the core) is another missing
piece.  (I've created such a prototype in the patch tracker somewhere.)
However, I was referring to going the other direction.

In some sense, these ideas could be done a bit differently just with the
ability to call a core function and get the information back by having
the GUI be a little smarter.  For example, the GUI could keep track of
the commands, say a table

table = {
   {"shg", &post_shg_func},
   {"dbstep", &post_dbstep_func},
   {"dbstop", &post_dbstop_func},
...
}

and generally do

   string cmd = gui_routine_that_deciphers_command (user_entered_command);
   rslt = call_background_function (cmd, arguments);
   int idx = is_in_table(cmd);
   if (idx)
      (*table[idx].func)( rslt );

However, the replication of the parser, and the fact a shell emulator is
in the mix complicates that a bit.

The overall theme is to utilize all the existing routines and the work
that has gone into programming them without having to roll a new
cross-link function for each command-line-initiated feature.  That
cross-link coding is fairly complicated and at the same time only done
from time to time, so each time it is a fair amount of work.

Dan