[Octave-patch-tracker] [patch #7990] Add builtin Qt equivalents of UI dialogs, i.e., , qterrordlg, qtinputdlg, etc.

[Dan Sebald]

Follow-up Comment #12, patch #7990 (project octave):

Yes someone could write a qterrordlg() script file.  But just as easily
someone could write an errordlg() script and override error dialogs.  In the
case of the Java dialogs there is this routine "javaMethod" in the namespace
that someone could override with a script file.

I've looked at the most recent setup for the GUI debugger.  There too are a
number of new functions in the name space.  Doing "add" then tab-completion
shows:


octave:6> add
add_dbclear_hook               add_pre_input_event_hook
add_dbstop_hook                addlistener
add_edit_hook                  addpath
add_enter_debugger_event_hook  addpref
add_exit_debugger_event_hook   addproperty
add_input_event_hook           adds/
add_post_input_event_hook      addtodate


Again, all functions that can be overridden.  What's more it overwhelms the
user who types "add" tab-complete with an array of functions.

Picking the "dbstop" feature as an example, in the GUI code the 


static octave_value_list
dbstop_hook_fcn (const octave_value_list& args, int)


is installed as the hook function via Fadd_dbstop_hook().  When that routine
is called, it will do a simple relay of the "args" variable to:


  octave_link::update_breakpoint_hook_fcn (true, args);


(Clear uses "false" instead of "true".)  That routine in turn interprets the
args, then apparently puts an event into:


              if (! error_state)
                {
                  event_listener->update_dbstop_marker (insert, file, line);
                  do_process_events ();
                }


That then does this:


octave_link::do_process_events (void)
{
  event_queue_mutex->lock ();

  gui_event_queue.run ();

  event_queue_mutex->unlock ();
}


At this point I'm going to stop trying to figure it out.  I can sort of guess.
 There is something on the GUI thread side that is going to have to interpret
that event in the queue and place a RedDot object of sorts in the editor
sidebar.  That has to be done indirectly because the hook above is called from
the Octave thread which cannot create GUI Qt objects, only non-GUI Qt objects.
 So there is this event queue mechanism, which I hope is efficient and not
some polling type of setup.

I think you'll agree that is getting quite convoluted.  And there is the extra
work of having to define these callback functions.  Break points is an easy
one.  Try expanding the idea to more advanced features.

It's just that it feels to me there should be a much more straightforward way.
 I'll first address the debug breakpoint feature, then propose another way to
incorporate variable GUI kits.

For the breakpoint set/clear, I'm imagining something quite simple using
signals and slots.  First there is a Qt object similar to the dialog-creator I
put in the patch.  Imagine for the time being the same setup as in the patch
attached here, i.e., it is written in C++ and accessible to Octave core.  What
I'm imagining is this debug_manager object emits a signal to its connected
slot in the editor object, say something like


connect (debug_manager, request_reddot (QString& filename, int linenumber)
         file_editor, handle_reddot_request (QString& filename, int
linenumber))


The debug_manager does


emit request_reddot (filename, linenumber);


That signal can go across threads.  The file_editor then creates a RedDot
object and places it in the editor.  It also makes some connections like:


RedDot *reddot = new RedDot(...);
/* Put reddot in container class, etc. */
connect (debug_manager, remove_breakpoint (QString& filename, int
linenumber),
         reddot, handle_remove_breakpoint (QString& filename, int
linenumber));
connect (reddot, request_remove_breakpoint (QString& command),
         octave_link, command (QString& command));


After that, it is the signals bouncing back and forth that manage the
behavior.  Say someone calls dbclear() at the command line.  That would cause
debug_manager to


emit remove_breakpoint (filename, linenumber);


That signal would go to every RedDot slot that is connected to it--could be
hundreds of slots connected to that signal.  Every RedDot would check if they
are the one associated with filename and linenumber.  If so, close and
destroy.

If the user points the mouse at the RedDot and clicks.  RedDot would


QString command;
command << "dbclear (""" << filename << """," << linenumber << ");"
emit request_remove_breakpoint (command);


That would go to the Octave thread, then Octave thread would run that command,
if successful the debug_manager would emit the signal that goes back to the
RedDot object slot and causes its removal.
         
I'll put comments about connecting Octave core and--for loss of better
term--builtins in a followup post.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?7990>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/