| 
     
      
      
      From: Erik T. <eri...@gm...> - 2008-09-23 05:20:24
      
     
   | 
Attached is a diff against revision 6115 that contains a patch to improve the behavior of the legend function when showing legends for Collections (e.g. pyplot.scatter plots). The implemented behavior shows three sample scatter points, adapting the properties and showing three different colors or sizes in the even that either vary across the points. However, this patch is not entirely correct - I've attached a testing script and an example of the output - as you can see, with a number of scatter plots, the alignment between the scatter symbols and the text is off in the legend. I suspect this has to do with the get_window_extent(self,render) function I had to add to the Collection class... I'm really not entirely sure what that function is supposed to do (or what coordinates it's supposed to be transformed into). Can anyone provide some guidance as to what should be done to fix this vertical offset problem?  | 
| 
     
      
      
      From: John H. <jd...@gm...> - 2008-09-23 18:53:47
       
   | 
On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote: > Attached is a diff against revision 6115 that contains a patch to > improve the behavior of the legend function when showing legends for Erik, I haven't had a chance to get to this yet. Could you please also post it on the sf patch tracker so it doesn't get dropped, and ping us with a reminder in a few days if nothing has happened.... JDH  | 
| 
     
      
      
      From: Erik T. <eri...@gm...> - 2008-10-01 06:48:20
       
   | 
Sorry for the dealyed reply - I've been out of town... I posted to the patch tracker, and am dutifully pinging :) On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote: > On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote: >> Attached is a diff against revision 6115 that contains a patch to >> improve the behavior of the legend function when showing legends for > > Erik, > > I haven't had a chance to get to this yet. Could you please also post > it on the sf patch tracker so it doesn't get dropped, and ping us with > a reminder in a few days if nothing has happened.... > > JDH >  | 
| 
     
      
      
      From: Erik T. <eri...@gm...> - 2008-10-07 04:16:31
       
   | 
Does anyone have anything new here? I'm perfectly willing to experiment, but I'm really at a loss as to what get_window_extent(self,render) is supposed to do (clearly get some window extent, but exactly what window and what coordinates the extent is in is what is confusing me). On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote: > On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote: >> Attached is a diff against revision 6115 that contains a patch to >> improve the behavior of the legend function when showing legends for > > Erik, > > I haven't had a chance to get to this yet. Could you please also post > it on the sf patch tracker so it doesn't get dropped, and ping us with > a reminder in a few days if nothing has happened.... > > JDH >  | 
| 
     
      
      
      From: Jae-Joon L. <lee...@gm...> - 2008-10-07 06:27:18
       
   | 
Hi Eric,
As far as I know, get_window_extent is meant to return the extent of
the object in the display coordinate. And, as you may have noticed,
often this is used to calculate the relative position of  objects.
I quickly went through your patch and my guess is your implementation
of get_window_extent is correct in this regard, but I haven't
considered this seriously so I may be wrong.
On the other hand, I guess the original problem you had is not related
with the get_window_extents() method.
The legend class has a _update_positions() method  which is called
before the legends are drawn. And you have to update positions of your
handles within this method.
In the simple patch below. I tried to implement some basic update code
for the polycollections ( I also slightly adjusted the y-offsets. This
is just my personal preference). See if this patch works for you.
Regards,
-JJ
Index: lib/matplotlib/legend.py
===================================================================
--- lib/matplotlib/legend.py	(revision 6163)
+++ lib/matplotlib/legend.py	(working copy)
@@ -532,6 +540,12 @@
             elif isinstance(handle, Rectangle):
                 handle.set_y(y+1/4*h)
                 handle.set_height(h/2)
+            elif isinstance(handle, RegularPolyCollection):
+                offsets = handle.get_offsets()
+                xvals = [x for (x, _) in offsets]
+                yy = y + h
+                yvals=[yy-4./8*h,yy-3./8*h,yy-4./8*h]
+                handle.set_offsets(zip(xvals, yvals))
         # Set the data for the legend patch
         bbox = self._get_handle_text_bbox(renderer)
On Tue, Oct 7, 2008 at 12:15 AM, Erik Tollerud <eri...@gm...> wrote:
> Does anyone have anything new here? I'm perfectly willing to
> experiment, but I'm really at a loss as to what
> get_window_extent(self,render) is supposed to do (clearly get some
> window extent, but exactly what window and what coordinates the extent
> is in is what is confusing me).
>
> On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote:
>> On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote:
>>> Attached is a diff against revision 6115 that contains a patch to
>>> improve the behavior of the legend function when showing legends for
>>
>> Erik,
>>
>> I haven't had a chance to get to this yet.  Could you please also post
>> it on the sf patch tracker so it doesn't get dropped, and ping us with
>> a reminder in a few days if nothing has happened....
>>
>> JDH
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
 | 
| 
     
      
      
      From: Erik T. <eri...@gm...> - 2008-10-09 03:27:13
       
  
        
          
            Attachments:
            scatleg.diff
          
        
       
     | 
Ah, that makes more sense Jae-Joon - thanks! With this addition it all looks fine to me - I've attached a patch against 6174 that does everything I'd like to see it do... note that I've left in the TODO in collections.py simply because I still am not certain that what I'm doing there is correct in all use-cases... On Mon, Oct 6, 2008 at 11:22 PM, Jae-Joon Lee <lee...@gm...> wrote: > Hi Eric, > > As far as I know, get_window_extent is meant to return the extent of > the object in the display coordinate. And, as you may have noticed, > often this is used to calculate the relative position of objects. > > I quickly went through your patch and my guess is your implementation > of get_window_extent is correct in this regard, but I haven't > considered this seriously so I may be wrong. > > On the other hand, I guess the original problem you had is not related > with the get_window_extents() method. > The legend class has a _update_positions() method which is called > before the legends are drawn. And you have to update positions of your > handles within this method. > > In the simple patch below. I tried to implement some basic update code > for the polycollections ( I also slightly adjusted the y-offsets. This > is just my personal preference). See if this patch works for you. > > Regards, > > -JJ > > > > Index: lib/matplotlib/legend.py > =================================================================== > --- lib/matplotlib/legend.py (revision 6163) > +++ lib/matplotlib/legend.py (working copy) > @@ -532,6 +540,12 @@ > elif isinstance(handle, Rectangle): > handle.set_y(y+1/4*h) > handle.set_height(h/2) > + elif isinstance(handle, RegularPolyCollection): > + offsets = handle.get_offsets() > + xvals = [x for (x, _) in offsets] > + yy = y + h > + yvals=[yy-4./8*h,yy-3./8*h,yy-4./8*h] > + handle.set_offsets(zip(xvals, yvals)) > > # Set the data for the legend patch > bbox = self._get_handle_text_bbox(renderer) > > > > On Tue, Oct 7, 2008 at 12:15 AM, Erik Tollerud <eri...@gm...> wrote: >> Does anyone have anything new here? I'm perfectly willing to >> experiment, but I'm really at a loss as to what >> get_window_extent(self,render) is supposed to do (clearly get some >> window extent, but exactly what window and what coordinates the extent >> is in is what is confusing me). >> >> On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote: >>> On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote: >>>> Attached is a diff against revision 6115 that contains a patch to >>>> improve the behavior of the legend function when showing legends for >>> >>> Erik, >>> >>> I haven't had a chance to get to this yet. Could you please also post >>> it on the sf patch tracker so it doesn't get dropped, and ping us with >>> a reminder in a few days if nothing has happened.... >>> >>> JDH >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 eto...@uc...  | 
| 
     
      
      
      From: John H. <jd...@gm...> - 2008-10-09 16:54:38
       
   | 
On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote: > Ah, that makes more sense Jae-Joon - thanks! Jae-Joon -- could you handle this patch submission? Thanks, JDH  | 
| 
     
      
      
      From: Jae-Joon L. <lee...@gm...> - 2008-10-09 17:11:52
       
   | 
Okay. I may work on it sometime tomorrow or during the weekends. Regards, -JJ On Thu, Oct 9, 2008 at 12:54 PM, John Hunter <jd...@gm...> wrote: > On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote: >> Ah, that makes more sense Jae-Joon - thanks! > > Jae-Joon -- could you handle this patch submission? > > Thanks, > JDH >  | 
| 
     
      
      
      From: Manuel M. <mm...@as...> - 2008-10-10 16:07:41
       
   | 
John Hunter wrote: > On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote: >> Ah, that makes more sense Jae-Joon - thanks! > > Jae-Joon -- could you handle this patch submission? > > Thanks, > JDH Hi, I also had a look at this patch -- as that's a feature I was interested in, too. There are a few things that I think need to be changed; just want to share my thoughts: - the parameter numpoints should be used (it's ignored right now) - Some private variables are accessed and a new RegularPolycollection is created (does this work eg. with a StarPolygonCollection? I haven't checked, but I don't think so !). Instead of creating a new RegularPolyCollection it might be more useful to make a copy of the existing object... I was thinking about a update_from() method for the Collection class(es) similar to update_from() for lines. mm > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel  | 
| 
     
      
      
      From: Jae-Joon L. <lee...@gm...> - 2008-10-13 02:19:26
       
   | 
> - the parameter numpoints should be used (it's ignored right now) > Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose. > - Some private variables are accessed and a new RegularPolycollection is > created (does this work eg. with a StarPolygonCollection? I haven't > checked, but I don't think so !). Instead of creating a new > RegularPolyCollection it might be more useful to make a copy of the > existing object... I was thinking about a update_from() method for the > Collection class(es) similar to update_from() for lines. > By changing "RegularPolyCoolection" to "type(handles)", it works for StarPolygonCollection. In Erik's current implementation, the markers in the legend have varying colors, sizes, and y offsets. The color variation seems fine. But do we need to vary the sizes and y-offsets? My inclination is to use a fixed size (median?) and a fixed y offset. How does Erik and others think? Regards, -JJ  | 
| 
     
      
      
      From: Manuel M. <mm...@as...> - 2008-10-13 20:12:06
       
   | 
Jae-Joon Lee wrote: >> - the parameter numpoints should be used (it's ignored right now) >> > > Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose. > > >> - Some private variables are accessed and a new RegularPolycollection is >> created (does this work eg. with a StarPolygonCollection? I haven't >> checked, but I don't think so !). Instead of creating a new >> RegularPolyCollection it might be more useful to make a copy of the >> existing object... I was thinking about a update_from() method for the >> Collection class(es) similar to update_from() for lines. >> > > By changing "RegularPolyCoolection" to "type(handles)", it works for > StarPolygonCollection. > In Erik's current implementation, the markers in the legend have > varying colors, sizes, and y offsets. > The color variation seems fine. +1 > But do we need to vary the sizes and > y-offsets? My inclination is to use a fixed size (median?) and a fixed > y offset. How does Erik and others think? I also would prefer fixed sizes for the legend, but maybe one should ensure that the markers are not too large (larger than text height)? mm > Regards, > > -JJ  | 
| 
     
      
      
      From: Manuel M. <mm...@as...> - 2008-10-15 19:58:54
       
  
        
          
            Attachments:
            scatleg.patch
          
        
       
     | 
Jae-Joon Lee wrote: >> - the parameter numpoints should be used (it's ignored right now) >> > > Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose. > > >> - Some private variables are accessed and a new RegularPolycollection is >> created (does this work eg. with a StarPolygonCollection? I haven't >> checked, but I don't think so !). Instead of creating a new >> RegularPolyCollection it might be more useful to make a copy of the >> existing object... I was thinking about a update_from() method for the >> Collection class(es) similar to update_from() for lines. >> > > By changing "RegularPolyCoolection" to "type(handles)", it works for > StarPolygonCollection. > > In Erik's current implementation, the markers in the legend have > varying colors, sizes, and y offsets. > The color variation seems fine. But do we need to vary the sizes and > y-offsets? My inclination is to use a fixed size (median?) and a fixed > y offset. How does Erik and others think? > > Regards, > > -JJ Attached is my current version of the patch. I've moved all of the properties-copying stuff to collections, which makes the changes legend.py more clearer (but I'm not fully happy with the patch and haven't commit anything yet) mm  |