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.
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. 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 > >
scatleg_jj.diff
Description: Binary data
------------------------------------------------------------------------- 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
