[Octave-bug-tracker] [bug #47585] GUI editor does not show already active breakpoints when a file is opened

[Dan Sebald]

Follow-up Comment #21, bug #47585 (project octave):

The changeset appears to work and is a good design.  This report can be
closed...  Consider using the octave_value_list via signal/slot for the many
other similar methods in the GUI; on a development branch perhaps.

I'm not sure how the current approach works, but there would need to be some
type of "update" signal/slot.  That is, every time the core worker process
does something there is a potential that the information in the GUI may have
changed, say in the variable editor.  It would be nice if there were some way
for objects to dynamically connect to this "update" signal so that they could
then inquire via this octave_value_list signal/slot for any updates.  (I would
investigate some means of asking only for that variable information which is
visible in the variable viewer, not say the whole big underlying matrix.)

Consider, though, the distinction between a user-driven change and an internal
state changed.  For example, "dbstop" is a user-driven state change.  In the
short term, it would be alright to keep inquiring about breakpoints after each
processing interval (or use whatever the current mechanism is), but in the
long run I think it would work much more efficiently if there were some way of
"installing" custom function overrides, say


GUI_dbstop
{
    call builtin dbstop;
    inquire about updated breakpoints via dbstatus;
}  


With such a construct the core worker process would be completely oblivious to
the need to update breakpoint info in the GUI.  That GUI_dbstop would be a
custom routine in the interpretter's function table somewhere.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?47585>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/