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
Locked
