bugGNU Octave - Bugs: bug #57260, scatter plot legend different from...

 
 

bug #57260: scatter plot legend different from previous releases

Submitted by:  Rik <rik5>
Submitted on:  Mon 18 Nov 2019 10:59:28 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Mon 09 Dec 2019 04:53:26 PM UTC, comment #5: 

I made minor changes, such as alphabetizing the lists of _creator_ types and checked your patch in here: https://hg.savannah.gnu.org/hgweb/octave/rev/0157c4d4792e.

I have some wish list items about the appearance of stem and errorbar legend keys which I will put in a different issue report.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Sun 08 Dec 2019 04:57:34 PM UTC, comment #4: 

@Rik: Thanks for the public congrats. I attached a patch that fixes this bug and improves the icons for contour(f), stem, quiver and errorbar plots. It also fixes bug #57262.

(file #48023)

Pantxo Diribarne <pantxo>
Project Member
Tue 26 Nov 2019 09:08:47 PM UTC, comment #3: 

>> This could be a good approach, as long as the writers of the scatter, stem, or other hggroup objects don't need to know about the internals of legend.m.  I'm worried that the phrase "add listeneres to target h_hggroup_obj object" may not be clear enough to them to figure out what to do.


After thinking about it a little more, it is probably much easier to have all the code in legend.m. The writers of hggroup specific legend code can then simply follow local examples. We would need to track which function created what hggroup, e.g. using a new hggroup string property "__creator__". We would also need to disentangle the code for item creation/positioning from the rest (the hardest task by far).

Pantxo Diribarne <pantxo>
Project Member
Tue 26 Nov 2019 12:05:16 AM UTC, comment #2: 

This could be a good approach, as long as the writers of the scatter, stem, or other hggroup objects don't need to know about the internals of legend.m.  I'm worried that the phrase "add listeneres to target h_hggroup_obj object" may not be clear enough to them to figure out what to do.

Maybe working through an example would help, and that example could be scatter since it is the subject of this report.  How does the _create_legend_item_fcn_ know how large to make the marker?  Even when the marker is excessively large, Matlab enforces a maximum within the legend key.  Sample code I used in to verify that assumption

clf;
x = randn (100, 1);
y = randn (100, 1);
h = scatter (x, y, "r");
title ("scatter() plot with red bubbles");
hl = legend ("Red Scatter");
set (h, 'linewidth', 2)
set (h, 'SizeData', 200)

It seems that enforcing this limitation, which would happen just once if done in legend.m, now needs to be communicated to any programmer of a _create_legend_item_fcn_ which means inevitably someone will make a mistake and not include it.

Rik <rik5>
Project Administrator
Sat 23 Nov 2019 12:58:59 PM UTC, comment #1: 

I would like to have a more robust way to determine how to handle legend item for special and/or compound hgroup objects in Octave.

For example we could define hidden hggroup properties "__create_legend_item_fcn__" and "__update_legend_item_fcn__". It would then be the responsability of scatter.m, stem.m, ..., to populate these properties so that legend doesn't have to know anything about the object it is labeling.

The prototype of those functions could be:

hitem  = __create_legend_item_fcn__ (h_hggroup_obj)
  ## Create necessary item objects. Add listeners to target
  ## h_hggroup_obj object. Return a handle to an hitem objects.
endfunction

and

__update_legend_item_fcn__ (hitem, [x0, x1, y0, y1])
  ## Handle the position of the existing hitem object based on
  ## the coordinates of a rectangular region.
endfunction

Thoughts?

Pantxo Diribarne <pantxo>
Project Member
Mon 18 Nov 2019 10:59:28 PM UTC, original submission:  

Sample code

color = [0; 0.5; 1];
h = scatter ([0.15, 1.15, -1.15],[2.15, 0, 1.15], 25, color);
legend (h, 'hello world');

Instead of having a single bubble with the specified color, there seem to be 4 bubbles with a different color.

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48023:  bug57260.patch added by pantxo (19KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

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

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-09 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2019-12-08 pantxo Attached File- => Added bug57260.patch, #48023
        StatusConfirmed => Patch Submitted
    2019-11-18 rik5 Carbon-Copy- => Added pantxo

    Back to the top


    Powered by Savane 3.5