I see most of your points and the current version is definitely better in many respects... I had originally tried to update the collections rather than make new ones, but didn't understand enough of the internals to implement the update_from method.
But regarding the size variation... I think the size variation is important because, in my view, the purpose of the legend for a scatter plot is to as accurately as possible reflect the data represented. I have certainly seen plots where there are two sets of symbols, one of which ranges over a bunch of sizes, and others that are uniform. If they appear almost the same on the legend, it takes much more time to figure out which is which, especially in cases where most of the symbols are small (so that the shape and color are somewhat harder to see). The eye is very good at picking out gross features in size variation, and I think that's important. I'm not totally stuck on it (I was somewhat dissatisfied in the initial implementation in that if you have very big or very small symbols, the legend is difficult to read... I meant to implement some smarter scaling of the legend but wanted to see what other people thought before doing that work). As for the y-offsets... The main justification there is to distinguish scatter plots from line plots that just aren't joining the points together. I personally have made plots where one set of data is best represented as data points with a trend, but it also makes sense to overlay a scatter plot of data on top of it. In that case, seeing data that appear "scattered" in the legend helps clarify the distinction between the two sets of data. So while I like most of the changes, I still think the y offsets and size variation should at least be an option (and I personally would want them on by default), although I am much more attached to the y-offsets than the size issue. Your thoughts? On Thu, Oct 16, 2008 at 4:43 AM, Manuel Metz <[EMAIL PROTECTED]> wrote: > Manuel Metz wrote: >> Jae-Joon Lee wrote: >>> Hi Manuel, >>> >>> I think it is a good to introduce the update_from method in Collections. >>> But, I'm not sure if it is a good idea to also update sizes, paths and >>> rotation (in RegularPolyCoolection). My impression is that update_from >>> method is to update gc related attributes. For comparison, >>> Patch.update_from() does not update the path. >> >> That's exactly the point why I wasn't fully happy with the patch. The >> path is generated by the _path_generator, so instead of copying the path >> it seems to be better to create an instance of the corresponding class >> (e.g. the StarPolygonCollection class, as suggested before). >> >> One should update the rotation attribute (!!); it's only one number. A >> '+' marker, for example, has rotation = 0, whereas a 'x' marker has >> rotation=pi/4. That's the only difference between those two ! >> >>> Also, is it okay to update properties without checking its length?. It >>> does not seem to cause any problems though. >> >> It's in principal not a problem to copy the sizes attribute without >> checking the length. If it's shorter the the number of items the sizes >> are repeated; if it's longer it gets truncated. >> >> mm >> >>> I guess It would better to use xdata_markers than xdata in the >>> get_handle() method. The difference is when numpoints==1. Using xdata >>> gives two marker points. >>> >>> I was actually about to to commit my patch. I'll try to account your >>> changes and post my version of patch later today. >>> >>> Regards, >>> >>> -JJ >>> >>> >>> >>> >>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: >>>> hmm >>>> >>>> -------- Original Message -------- >>>> 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 >>>> > > Hi Jae-Joon, > so here is my revised version of the patch. What do you think ? > > Manuel > > > ------------------------------------------------------------------------- > 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 > Matplotlib-devel@lists.sourceforge.net > 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 [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
