[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #47585] GUI editor does not show already activ

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #47585] GUI editor does not show already active breakpoints when a file is opened
Date: Sat, 13 Oct 2018 12:01:39 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

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

    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:


  Message sent via Savannah

reply via email to

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