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: Tue, 12 Dec 2017 13:10:34 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

Well, think about it a bit.  It sort of does make sense for updatename to be
its own function.  Each of these objects in the legend has its own name.  In
fact, the __getlegenddata__ main loop is constructed as


    if (any (strcmp (typ, {"line", "patch", "surface", "hggroup"})))
      dname = get (kids(i), "DisplayName");


which is somewhat generic.

And if there is an updatepatch, updatesurface (which is a good idea) it's
likely that its code for updating its name will be a replica of the code under
"if (update_name)" in the updateline callback.  So, updatename callback can be
used for all these different graphics object types just using a different
handle.

I don't see many places outside __getlegenddata__.m and legend.m where
__getlegenddata__ is used.  There are only:


sebald@ ~/octave/octave/octave $ grep getlegenddata */*/*/*/* -s
scripts/plot/draw/private/__errplot__.m:      [hlgnd, tlgnd] =
__getlegenddata__ (hlegend);
scripts/plot/draw/private/__plt__.m:      [hlgnd, tlgnd] = __getlegenddata__
(hlegend);


For the __errplot__.m routine, it just tags some extra items at the end of the
current hlgnd and tlgnd and calls legend() to set the new names.  In the case
of __plt__.m, it's pretty much the same inside the __plt_key__ subfunction. 
So, there really isn't any case where hlgnd or tlgnd are used in a conditional
way that might cause an error.  I don't think there would be any new issues
with a change to __getlegenddata__.  I wonder if anyone has actually generated
plots in which the strings are empty.

In fact, I was trying to imagine how the __getlegenddata__ could be moved
inside of legend.m and re-used in some way.  Inside legend.m there are a bunch
of loop constructs that are almost identical to what __getlegenddata__ is
doing, i.e., testing for "surface", "patch", "line" inside some loop.  Not
critical, but just good coding practice to reuse things.

Also, perhaps there is some way to add plot objects to legends without first
calling __getlegenddata__ and then appending to the end of the list--although,
it is convenient to do so.  But still, the convention seems to be

hold on
SOMEPLOTFUNC(...,'displayname','keyname')

So, perhaps __errplot__.m can use that route instead.

    _______________________________________________________

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]