No more thoughts on this? Or was some version of the patch committed? On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: > Actually, looking more closely, there is one thing that's still > bothering me: as it is now, it's impossible to have, say, 2 points > for plotted values, and 3 points for scatter plots on the same legend > (you have to give a numpoints=# command that's shared by everything in > the legend, if I'm understanding it). It'd be nice to have a > property, say, "scatterpoints" (and presumably then an associated > rcParam "legend.scatterpoints" ) that sets the number of points to use > for scatter plots. That way, I can make plots just like in the > original form, but it can also be the same number for both if so > desired. I've attached a patch based on the last one that does this, > although it probably needs to be changed to allow for an rcParam > 'legend.scatterplot' (I don't really know the procedure for adding a > new rcParam). > > On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote: >> The current patch looks good to me... it satisfies all the use cases I >> had in mind, and I can't think of much else that would be wanted. >> Thanks! >> >> I also very much like the idea of the "sizebar," although that's >> probably a substantially larger job to implement. I may look into it >> though, time permitting... >> >> On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: >>>> To help clarify the original purpose of "update_from": I wrote this >>>> method when writing the original legend implementation so the legend >>>> proxy objects could easily copy their style attributes from the >>>> underlying objects they were a proxy for (so not every property is >>>> copied, eg the xdata for line objects is not copied). So the >>>> operating question should be: what properties do I need to copy to >>>> make the legend representation of the object. While you are in >>>> there, perhaps you could clarify this in the docstrings of the >>>> update_from method. >>> >>> Thanks for clarifying this, John. >>> >>> Manuel, >>> The patch looks good to me. We may submit the patch (I hope Erik is >>> okay with the current patch) and it would be great if you handle the >>> submission. >>> >>> -JJ >>> >>> >>> >>> >>> >>> On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: >>>> Jae-Joon Lee wrote: >>>>> Thanks Manuel. >>>>> >>>>> Yes, we need rotation value and etc, but my point is, do we need to >>>>> update it within the update_from() method? Although my preference is >>>>> not to do it, it may not matter much as far as we state what this >>>>> method does clearly in the doc. >>>> >>>> Okay, it's probably better to create the object correctly (numsides ...) >>>> instead of copying the properties (see also JDHs mail !) >>>> >>>>> And, in your patch, I don't think updating the numsides value has any >>>>> effect as it does not recreate the paths. >>>>> >>>>> I'm attaching the revised patch. In this patch, update_from() only >>>>> update gc-related properties. And numsides, size, and rotations are >>>>> given during the object creation time. >>>> >>>> Yes, this looks better. But creating handle_sizes is a little bit too >>>> much effort. This is done internally. It will do passing a sizes list, >>>> that may or may not be shorter/longer than numpoints (see revised patch). >>>> >>>> I also changed the way the yoffsets are updated in _update_positions(). >>>> >>>> One additional thing I have in mind (for a later time) is a "sizesbar" >>>> similar to a colorbar where you can read off values corresponding to >>>> marker sizes... >>>> >>>> Cheers, >>>> Manuel >>>> >>>>> Erik, >>>>> I see your points. My main concern is that the yoffsets makes the >>>>> results a bit funny when numpoints is 2. The attached patch has a >>>>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only >>>>> introduced when numpints > 2 and you can also provide it as an >>>>> optional argument. >>>>> >>>>> Regards, >>>>> >>>>> -JJ >>>>> >>>>> >>>>> On Thu, Oct 16, 2008 at 8:43 PM, 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 >>>> >>>> >>> >>> ------------------------------------------------------------------------- >>> 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] >
-- 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
