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 > ------------------------------------------------------------------------- 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
