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.