[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 13:47:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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() followed
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 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);

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

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.


reply via email to

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