[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Qt help w/bug #45943

From: Daniel J Sebald
Subject: Re: Qt help w/bug #45943
Date: Wed, 15 Aug 2018 14:59:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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

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()
by raise() would work.  See


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
interpreter thread could reach so that shg will work.  I suppose this
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);

(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:




Then the GUI's construct for implementing the routine would be, for

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

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]