octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #52641] Changing legend "displayname" property


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52641] Changing legend "displayname" property to empty string "" leads to printing an error
Date: Wed, 13 Dec 2017 14:28:30 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #13, bug #52641 (project octave):

I looked at legend.m more deeply last night.  Whoo, that's one patchwork of
disparate ideas.  There's storing handles for later use, state variables to
prevent processing callbacks, persistent variables for the same purpose.  This
really could use an overhaul.  If one wanted to stick to the callback idea,
I'd suggest

1) Drop the use of "userdata" everywhere.  Not only is it legend.m where this
"userdata" variable is being used to store things.

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.

Question, isn't the legend supposed to be associated with an axes rather than
a figure?


octave:2> h = plot (10:-1:1, "o-;Legend String;", -[1:10], ";Leg End
String;");
octave:3> kids = get(gcf, 'Children')
kids =

  -8.3648
  -1.3944

octave:5> get(kids(1))
ans =

  scalar structure containing the fields:

    edgecolor =

       0   0   0

    interpreter = tex
    location = northeast
    orientation = vertical
    string =
    {
      [1,1] = Legend String
      [1,2] = Leg End String
    }

    textcolor =

       0   0   0

    textposition = right
    unmodified_axes_outerposition =


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52641>

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




reply via email to

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