[Top][All Lists]

[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

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__

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

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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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