matplotlib-devel Mailing List for matplotlib

Jae-Joon Lee wrote:
> John,
> 
> The current legend class has following options given in axes units.
> 
> pad, labelsep, handlelen, hadletextsep, axespad
> 
> Eric introduced borderpad (given as a fraction of the font size),
> which replaces "pad".
> One way is to introduce new names for all of above options. Eric's
> suggestion was (in my understanding) to use same names, but have a
> some way to select between the old behavior and the new one.
> And my inclination was to go with Eric's suggestion instead of
> inventing new names. Anyhow, I'm happy with either approach.
> If we're inventing new option names, I guess there would be no problem
> I mentioned in the previous mail.
Assuming good, descriptive names can be found--whether recycling the old 
ones or choosing new ones--the larger question is what the preferred 
units should be for which options. I think it makes sense for axespad 
to remain in axes units, but all the others seem most natural to me in 
fraction of the font size, not in points. With the former, it is like 
specifying "doublespace" in a document; the whole legend, and everything 
in it, should have proportions that are scale-independent and font-size 
independent. With points, you have to adjust 4 options if you change 
your font size. I think that *all* pads involving text placement should 
 scale with the corresponding font size. This applies to tick label 
pads, axis label pads also. That way, if you need to make a figure for 
publication or beamer display, with extra-large text, it will look right 
when you merely change the font sizes--you won't have to adjust all the 
pads at the same time.
Eric
> 
> Regards,
> 
> -JJ
> 
> 
> On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <jd...@gm...> wrote:
>> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee...@gm...> wrote:
>>> Basic idea is to create a new version of the Legend class with a same
>>> interface to the current one.
>>> Eric's original suggestion was to use some optional kwarg to choose the version.
>>> But I found this approach does not work well unless we also set the
>>> meaningful default values in the rc file. For example, the current
>>> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
>>> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
>>> the font size) in the new class.
>> I think we should deprectate the axes pad kwarg. If you see it coming
>> in (not None), make a reasonable points approximation to a pad using
>> the figure dimensions and axes dimensions and dpi, and issue a warning
>>
>> padpoints = # compute something here from figsize, axes rect and axespad
>> warnings.warn("axespad is a deprecated argument to legend. The
>> new argument is "padpoints" and is in points. Assuming %1.1f
>> ponts"%padpoints)
>>
>> That way we won't go crazy supporting 2 versions of something, users'
>> code won't break initially or fail silently, nd users will have a
>> clear migration path.
>>
>> Does that work? Anyone who is using axespad is something of a power
>> user and will have no problem fixing up their code.
>>
>> 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

On Fri, Oct 31, 2008 at 5:12 AM, Jae-Joon Lee <lee...@gm...> wrote:
> But I guess this can be simplified.
> And, I may gather those Connector classes under a single class (or a
> module). And same for arrowstyle classes and boxstyle classes.
Yes, I think this is the way to go -- uses classes for all of these
rather than strings.
JDH

John,
The current legend class has following options given in axes units.
 pad, labelsep, handlelen, hadletextsep, axespad
Eric introduced borderpad (given as a fraction of the font size),
which replaces "pad".
One way is to introduce new names for all of above options. Eric's
suggestion was (in my understanding) to use same names, but have a
some way to select between the old behavior and the new one.
And my inclination was to go with Eric's suggestion instead of
inventing new names. Anyhow, I'm happy with either approach.
If we're inventing new option names, I guess there would be no problem
I mentioned in the previous mail.
Regards,
-JJ
On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> Basic idea is to create a new version of the Legend class with a same
>> interface to the current one.
>> Eric's original suggestion was to use some optional kwarg to choose the version.
>> But I found this approach does not work well unless we also set the
>> meaningful default values in the rc file. For example, the current
>> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
>> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
>> the font size) in the new class.
>
> I think we should deprectate the axes pad kwarg. If you see it coming
> in (not None), make a reasonable points approximation to a pad using
> the figure dimensions and axes dimensions and dpi, and issue a warning
>
> padpoints = # compute something here from figsize, axes rect and axespad
> warnings.warn("axespad is a deprecated argument to legend. The
> new argument is "padpoints" and is in points. Assuming %1.1f
> ponts"%padpoints)
>
> That way we won't go crazy supporting 2 versions of something, users'
> code won't break initially or fail silently, nd users will have a
> clear migration path.
>
> Does that work? Anyone who is using axespad is something of a power
> user and will have no problem fixing up their code.
>
> JDH
>

Sorry Erik.
Can you make a new patch against the current SVN?
Some of the patch was applied (but without scatterpoints option) in the SVN.
Thanks,
-JJ
On Thu, Oct 30, 2008 at 1:58 PM, Erik Tollerud <eri...@gm...> wrote:
> No more thoughts on this? Or was some version of the patch committed?
>
> On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <eri...@gm...> 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 <eri...@gm...> 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 <lee...@gm...> 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 <mm...@as...> 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 <mm...@as...> 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 <mm...@as...> 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
>>>>> Mat...@li...
>>>>> 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
>>>> 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...
>>
>
>
>
> --
> 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...
>

John,
Thanks for the advice. I'll try to put some mre effort on the documentation.
> - is using a string for connectionstyle the best choice? Ie, instead of::
>
> connectionstyle="angle,angleA=0,angleB=90,rad=10"
>
> would we rather have something like::
>
> connectionstyle=connectionstyle.angle(angleA=0,angleB=90,rad=10)
>
> The latter looks more pythonthic and extensible, because if we document the
> connectionstyle API users can provide their own.
Yes, I agree.
As you know, I used strings for the "boxstyle" and the "arrowstyle"
also, in a similar way of linestyle.
But the string for connectionstyle seems to get too complicated.
It is currently possible to do something like below,
 connetionstyle="custom",
 connector=patches.AngleConnector(angleA=0, angleB=90, rad=10)
But I guess this can be simplified.
And, I may gather those Connector classes under a single class (or a
module). And same for arrowstyle classes and boxstyle classes.
Regards,
-JJ