bugGNU Octave - Bugs: bug #50483, legend hide fails for gnuplot...

 
 

bug #50483: legend hide fails for gnuplot since v4.0.3

Submitted by:  Rik <rik5>
Submitted on:  Tue 07 Mar 2017 04:39:07 PM UTC  
 
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.0.3Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 02 Aug 2017 07:05:44 PM UTC, comment #12:

Oh, I thought FLTK was compatible. Good change then.

Dan Sebald <sebald>
Wed 02 Aug 2017 06:37:45 PM UTC, comment #11:

There is no reason to behave like the FLTK toolkit. It is an artifact of the FLTK implementation that there are both line and text objects for each actual object being labeled.

I removed the last line from the if statement, and also re-coded the patch to eliminate the call to cell2mat. It's not that big of a performance concern, but it will be faster if the parser can do the work rather than going out to an m-file.

I checked in the cset here http://hg.savannah.gnu.org/hgweb/octave/rev/ff2c2f2f6702.

Rik <rik5>
Project Administrator
Wed 02 Aug 2017 05:00:13 PM UTC, comment #10:

I was going to ask about that. Did you try the example from the last post with FLTK toolkit to see how the individual items can be controlled? In summary there are six elements in question here whose visibility can be set:

For FLTK all of the above can be controlled individually. So, for FLTK one could remove all six of those elements from the plot and there is still a square box present for the legend.

That behavior is different from the logic of gnuplot toolkit that we are discussing. With the line you point out, as it stands, either doing this:

or doing this

results in the total removal of the key. Also, we can't individually control the legend items, e.g.,

does nothing different than if all the legend items are visible. So, in that sense, the line you point out really isn't doing a whole lot as far as the gnuplot toolkit goes.

Keep that line of code, remove the line--doesn't matter too much. And to make gnuplot toolkit behave more like FLTK toolkit would mean--not a significant rewrite--but enough change that it would probably substantially rewrite this conditional logic. But I'm not too concerned about getting a perfect match between FLTK and gnuplot toolkit because I don't imagine individual key item visibility properties as getting much traffic. Typically, if someone doesn't want a line on a plot, s/he will simply not include it in the script as opposed to plotting it and then setting the visibility to off, or put "" for the key text, etc. The only way I could imagine this being used is if someone could manually interact with a plot and, say, right click the plot object or its property to toggle in/visible.

I guess I lean toward leaving the line of code in place, but don't feel strongly one way or another.

Dan Sebald <sebald>
Wed 02 Aug 2017 03:40:18 PM UTC, comment #9:

@Dan: In your cset, is the existing line which checks for the visibility of hlgnd.children necessary anymore?

I tried deleting it and the plot behavior seemed correct.

Rik <rik5>
Project Administrator
Wed 02 Aug 2017 05:52:58 AM UTC, comment #8:

Attached is a small changeset for what you are describing.

However, I'm not sure what you are thinking is the proper behavior because each of the legend children has its own independent 'visible' setting. gnuplot can't do such a thing at the moment (it probably could be done still, but the complexity of code doesn't pay for the likelihood of the user getting so detailed.

But FLTK seems to handle the legend children settings. Try the following:

FLTK behaves different, but it seems more proper given the settings.

(file #41389)

Dan Sebald <sebald>
Wed 02 Aug 2017 12:19:39 AM UTC, comment #7:

@Dan: I believe the reason to check visibility is for cases where an object is plotted, labeled, but eventually hidden. This test code shows how it works

While the code above works perfectly, there is a problem if the number of objects drops to 0. At that point the legend still contains an entry which is a magenta line and the literal text "-". Try this

If it were easy to fix it would be nice to do so.

Rik <rik5>
Project Administrator
Wed 02 Aug 2017 12:13:17 AM UTC, comment #6:

@Tejaswi: I added your name to the contributors and checked in the change here (http://hg.savannah.gnu.org/hgweb/octave/rev/5b5b021b1476). I also added some standard documentation to make it a complete changeset, i.e., 1) a one-liner summary, and 2) a list of what was changed in each file modified. You can have a look at the web link if you want to see the syntax.

Rik <rik5>
Project Administrator
Tue 01 Aug 2017 08:09:07 PM UTC, comment #5:

@Rik: That would be great! My name is - Tejaswi D Prakash and email address is tejaswidp@protonmail.com.

@Dan: I believe you are right in that the way the legend visibility works has changed. While looking into this issue I found that the "visible" attribute for all of hlgnd.children is not set, but the value for hlgnd.visible is set correctly(on|off).
Although I've not tested the script after removing the condition you've posted.

Tejaswi <widp>
Tue 01 Aug 2017 06:43:10 PM UTC, comment #4:

This patch fixes the issue for the test script.

Did it break because something was changed about how legend visibility works (that's my recollection)? There is this test:

but then later nothing loops through the various children. Individually controlling key entries doesn't suit gnuplot, so any visible means all visible in the key. That's probably an OK trade off, otherwise it would mean Octave script code to construct the whole legend/key.

Dan Sebald <sebald>
Tue 01 Aug 2017 06:29:42 PM UTC, comment #3:

@Tejaswi: We usually acknowledge contributors to Octave by adding them to the list at the front of the Octave manual. Would you like to be credited? Secondly, we usually check in a change with a person's name and contact e-mail so they can be reached if there is an issue with a patch. Do you have a name and e-mail that you would like to use? If not, I can check the change in under my own credentials.

Rik <rik5>
Project Administrator
Tue 01 Aug 2017 05:32:59 PM UTC, comment #2:

I'll let Dan review the patch since he is the gnuplot expert.

Rik <rik5>
Project Administrator
Tue 01 Aug 2017 05:07:30 PM UTC, comment #1:

Attaching a patch which resolves this for me. New contributor here.

(file #41382)

Tejaswi <widp>
Tue 07 Mar 2017 04:39:07 PM UTC, original submission:

The ability to hide the legend with the gnuplot toolkit was lost in between version 4.0.2 and 4.0.3. The problem persists through the 4.2.X series and in the development version.

Sample code:

For reference, my version of gnuplot is 5.0.1.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #41382:  path.diff added by widp (492B - text/x-patch - I narrowed down the problem to the _gnuplot_draw_axes_.m file and I have attached a diff. Please take a look)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by widp (Updated the item)
  • -unavailable- added by rik5 (You might know if there is a trivial fix for this)
  • -unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 02 Aug 2017 05:52:58 AM UTCsebaldAttached File-=>Added octave-legend_conditional_gnuplot-djs2017aug02.patch, #41389
    Wed 02 Aug 2017 12:13:17 AM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Tue 01 Aug 2017 05:32:59 PM UTCrik5StatusConfirmed=>Patch Submitted
    Tue 01 Aug 2017 05:07:30 PM UTCwidpAttached File-=>Added path.diff, #41382
    Thu 16 Mar 2017 09:07:56 PM UTCrik5Carbon-Copy-=>Added sebald

    Back to the top


    Powered by Savane 3.1-cleanup1