[Octave-task-tracker] [task #14243] Rewrite legend.m

[Dan Sebald]

Follow-up Comment #4, task #14243 (project octave):

Investigating bug #52641 led me to look more closely at legend.m.  My
suggestion is to make this more listener/callback oriented and get rid of some
of the old-convention techniques like persistent variables, etc.  If one gets
in the listener/callback frame of mind it becomes much easier to realize
simpler ways of doing things.

1) Drop the use of "userdata" everywhere. Not only is it legend.m where this
"userdata" variable is being used to store things.  "UserData" is for the user
to use as desired.  Even if some of these objects typically don't have a
UserData counterpart in Matlab, if the user decides to use some legend
"userdata" it will disrupt the legend.

2) Make the listeners more abundant and at the same time smaller hunks. That
is the typical strategy of callback-based frameworks. The behavior lies in all
the connections made. For example, rather than reconstructing the legend via
calling legend() again and again, there could be listeners tied to the axes
children list. If the children list changes (due to addition of another plot
item, e.g., "hold on") it could trigger a reconstruction of the plot.
Listeners could be tied to the name text objects such that if one of those
text objects changes--either directly or via "set(hax, 'displayname',
'newname')" which in itself triggers some callbacks--it will trigger a
re-layout of the plot.

3) The way that the current-axes and legend-handle are derived seems far more
complex than it needs to be. If the input is a valid axes handle, use that,
otherwise gca() does the job, even constructing the axes if they don't exist.
All that searching of the ancestor tree should be replaced by something far
more simple.

4) With regard to the reoccurring scanning of ancestors and kids, it might be
better to place more information in the list of arguments to listeners. It
makes the number of variables passed around greater, but at the same time it
saves running a hunk of code to reconstruct that info.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?14243>

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