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

I realised in my earlier message, I didn't really address your initial 
request for feedback on your approach.
I think the goal here should be to make the url support as pervasive as 
possible wrt both plot types and backends.
Many of the high-level plotting functions (such as bar()) take a 
standard set of "Artist" keywords. In the docs, you'll often see a 
table like the one at the bottom for bar():
 
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar
This support all happens automatically simply by adding a setter and 
getter to the "Artist" class. So, in Artist, simply add set_url/get_url 
methods and a private attribute to store the url. You shouldn't have to 
touch any of the high-level plotting functions to have this supported 
everywhere where it makes sense.
Then, to use the url value, you'll want to store it in a GraphicsContext 
object to pass to the backend. So you'll want to add an attribute and 
getter/setter in GraphicsContextBase as well.
All of the places where the front-end creates a gc and passes it to the 
backend will need to be updated (such as Artist.draw, Text.draw, perhaps 
others, do a grep for the public methods in RendererBase). Where it 
sets things like facecolor on the GraphicsContext, it should also set a url.
Then, in backends where appropriate you would use the url value if 
present. You could start with SVG, and maybe someone can come along and 
add PDF support later.
An additional complication for completeness is handling Collections. 
Collections store a list of graphics context information (facecolor, 
edgecolor etc.) rather than a single one. Therefore, you'll want to add 
set_urls/get_urls to Collection as well, and then deal with passing 
those values to the backend. Collections don't use a GraphicsContext 
class, so you'll need to add a new arg to draw_path_collection in all 
backends. (Refactoring this so we pass an object to the backends rather 
than a long list of arguments would be welcome to avoid needing to 
update multiple backends for these sorts of new features in the 
future). You will also need to update RendererBase._iter_collection to 
support iterating over URLs in the same way as everything else there.
draw_image also doesn't use a gc, so you'll need to add an argument there.
Hope that gives you a road map... Please let me know if I can help further.
Mike
Andrew Stock wrote:
> Hi,
>
> I have a requirement to make clickable bar charts using the SVG output
> (rather than html maps).
>
> An initial look has suggested that the following changes would be required:
>
> backend_bases.py: Add a url property to GraphicsContextBase
> (defaulting to None, so it's all backwards compatible)
> axes.py: Add a url option to the bar function and pass this on to the
> constructor of the Rectangle object
> patches.py: Pass the url option in the constructor for the Patch
> object to the GraphicsContextBase object created in the draw function
> backends/backend_svg.py: Add check to _draw_svg_element for url set in
> gc. If it is, write out SVG code for xlink.
>
> I can make these changes and (if people think it would be useful)
> contribute the changes back. However, before I do this, I wanted to
> check whether this is the right approach to take - I'm not experienced
> with the internals of matplotlib and so if there's a better way of
> doing it, I'd be grateful for the advice.
>
> Once I got the bar charts working, I would be interested in possibly
> extending this to other chart types.
>
> Regards
>
> Andrew
>
> -------------------------------------------------------------------------
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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

Pierre GM wrote:
> All (with a special hello to Jeff W.),
> I'm running into a problem with the latest basemap (r6355), illustrated in the 
> following. Looks like the resolution 'i' causes a TopologyException
>
> GEOS_ERROR: TopologyException: found non-noded intersection 
> between -42.7171 -2.56422, -42.7313 -2.57589 
> and -42.7059 -2.58961, -42.7475 -2.56714 -42.7313 -2.57589
>
> Note that it works at lower resolution, and works also when using 
> basemap-0.9.6.1
> 
Hi Pierre: Version 0.9.6.1 didn't use the GEOS library. Your example 
works for me with geos 2.2.3, so I suspect you're using geos 3? I've 
found that geos version 3 is a bit buggy, and chokes on coastline 
polygons that geos 2.2.3 handles perfectly well. I have geos 3 
installed at home, so I'll try your example when I get home today and 
see if I can find a workaround.
> _____
> use_new = False
> if use_new:
> from mpl_toolkits.basemap import Basemap
> else:
> from matplotlib.toolkits.basemap import Basemap
> (llcrnrlon, llcrnrlat, urcrnrlon, urcrnrlat) = (-86.50, 30.50,-80.00, 35.01)
> for resolution in (None,'l','i','h'):
> basemap = Basemap(projection='aea',
> llcrnrlon=llcrnrlon,llcrnrlat=llcrnrlat,
> urcrnrlon=urcrnrlon,urcrnrlat=urcrnrlat,
> lat_1=29.5,lat_2=45.5,lat_0=23,lon_0=-96,
> resolution=resolution)
> print 'resol',resolution
> _____
>
>
> As a side note, would it be possible for the config script to search whether 
> GEOS is installed in /usr ?
> 
Done (r6357).
-Jeff
> Any suggestion/cooment welcome,
> Thanks a lot in advance
> P.
>
> -------------------------------------------------------------------------
> 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
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

All (with a special hello to Jeff W.),
I'm running into a problem with the latest basemap (r6355), illustrated in the 
following. Looks like the resolution 'i' causes a TopologyException
GEOS_ERROR: TopologyException: found non-noded intersection 
between -42.7171 -2.56422, -42.7313 -2.57589 
and -42.7059 -2.58961, -42.7475 -2.56714 -42.7313 -2.57589
Note that it works at lower resolution, and works also when using 
basemap-0.9.6.1
_____
use_new = False
if use_new:
 from mpl_toolkits.basemap import Basemap
else:
 from matplotlib.toolkits.basemap import Basemap
(llcrnrlon, llcrnrlat, urcrnrlon, urcrnrlat) = (-86.50, 30.50,-80.00, 35.01)
for resolution in (None,'l','i','h'):
 basemap = Basemap(projection='aea',
 llcrnrlon=llcrnrlon,llcrnrlat=llcrnrlat,
 urcrnrlon=urcrnrlon,urcrnrlat=urcrnrlat,
 lat_1=29.5,lat_2=45.5,lat_0=23,lon_0=-96,
 resolution=resolution)
 print 'resol',resolution
_____
As a side note, would it be possible for the config script to search whether 
GEOS is installed in /usr ?
Any suggestion/cooment welcome,
Thanks a lot in advance
P.

On Thu, Oct 30, 2008 at 9:28 AM, Darren Dale <dar...@co...> wrote:
> Line 2900 in patches.py is not compatible with python-2.6. "as" is protected
> and cannot be used as a variable name.
good catch - -fixed in r6355
JDH

Line 2900 in patches.py is not compatible with python-2.6. "as" is protected 
and cannot be used as a variable name.
On Thursday 30 October 2008 09:49:24 am John Hunter wrote:
> On Thu, Oct 30, 2008 at 12:32 AM, Jae-Joon Lee <lee...@gm...> wrote:
> > John and others,
> >
> > I submitted a patch of the fancy arrow I mentioned a while ago.
> >
> > http://sourceforge.net/tracker2/?func=detail&aid=2209021&group_id=80706&a
> >tid=560722
>
> Hi Jae Joon -- sorry for not responding. I had completely missed
> this. Reminding us on the mailing list is definitely a good idea
> because I tend to fall behind quite often.
>
> The patch and new example look great. My only requests for changes
> (or for next time) are stylistic:
>
> - when making a significant contribution like this, please add a
> change to the CHANGELOG, since that is what many people use to see
> what's new and what we use to make the release notes. I've done this
> already for this one.
>
> - try and document every method using the rest documentation
> conventions. See
> http://matplotlib.sourceforge.net/devel/documenting_mpl.html. Since
> we have been working hard on the website and API docs, the one thing
> I'd like to ask of you is to make sure all the docstrings are updated
> including a bit of module level documentation in bezier -- then I will
> add bezier to the API docs
>
>
> - for triple quoted docstrings, I would like to stick to the format::
>
> def myfunc(args):
> """"
> this is my docstring
> """"
>
> rather than
>
>
> def myfunc(args):
> """"this is my docstring
> """"
>
> - I renamed bezier_util to bezier (PEP8 style guide advises to avoid
> underscores and make module names as short as is reasonable), and we
> should import it with the full name "from matplotlib.bezier import
> ..." rather than "from bezier import ..."
>
> - 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.
>
> These are of course mostly minor stylistic nits, but I want the code
> to be as uniform as possible.
>
> I've committed this to svn r6353, and updated the website, so you can
> see your examples in the gallery and examples pages:
>
> http://matplotlib.sourceforge.net/gallery.html
> http://matplotlib.sourceforge.net/gallery.html
>
> Very nice contribution!
> 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
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Another use case in favor of implementation of the URL property at the
artist level:
Consider a map with scatter points representing geolocated photos that
can be viewed at some URL. Attach a mouse click on the artist to the
following code:
import webbrowser
webbrowser.open(patch.url)
And you have an interactive map that lets you grab remote data.
-Eric
On Thu, Oct 30, 2008 at 10:02 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 30, 2008 at 8:10 AM, Michael Droettboom <md...@st...> wrote:
>
>> In the specific case of bar(), one may still be forced to manually set
>> urls on each Rectangle if one wants those urls to be different. But
>> this is no different than the current situation wrt facecolor or any
>> other attribute, since bar is not written on top of Collection.
>
> better yet would be to replace the list of rectangles with a patch
> collection, do the same for pie, etc. Then a single URL on the
> collection would apply to the batch. This would break a fair amount
> of code, but we might be able to minimize the pain by providing an
> iter interface and a getitem interface to the collection, which warns
> and does the right thing. So users who did
>
> # bars was a list of Rectangles, now it is a PatchCollection
> for bar in bars:
> bar.set_facecolor('red')
>
> would get working code and a warning telling them to just do
> bars.set_facecolors instead.
>
> And, yes, the example is *very cool*
>
> 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 Thu, Oct 30, 2008 at 8:10 AM, Michael Droettboom <md...@st...> wrote:
> In the specific case of bar(), one may still be forced to manually set
> urls on each Rectangle if one wants those urls to be different. But
> this is no different than the current situation wrt facecolor or any
> other attribute, since bar is not written on top of Collection.
better yet would be to replace the list of rectangles with a patch
collection, do the same for pie, etc. Then a single URL on the
collection would apply to the batch. This would break a fair amount
of code, but we might be able to minimize the pain by providing an
iter interface and a getitem interface to the collection, which warns
and does the right thing. So users who did
# bars was a list of Rectangles, now it is a PatchCollection
for bar in bars:
 bar.set_facecolor('red')
would get working code and a warning telling them to just do
bars.set_facecolors instead.
And, yes, the example is *very cool*
JDH

On Thu, Oct 30, 2008 at 12:32 AM, Jae-Joon Lee <lee...@gm...> wrote:
> John and others,
>
> I submitted a patch of the fancy arrow I mentioned a while ago.
>
> http://sourceforge.net/tracker2/?func=detail&aid=2209021&group_id=80706&atid=560722
Hi Jae Joon -- sorry for not responding. I had completely missed
this. Reminding us on the mailing list is definitely a good idea
because I tend to fall behind quite often.
The patch and new example look great. My only requests for changes
(or for next time) are stylistic:
 - when making a significant contribution like this, please add a
change to the CHANGELOG, since that is what many people use to see
what's new and what we use to make the release notes. I've done this
already for this one.
 - try and document every method using the rest documentation
conventions. See
http://matplotlib.sourceforge.net/devel/documenting_mpl.html. Since
we have been working hard on the website and API docs, the one thing
I'd like to ask of you is to make sure all the docstrings are updated
including a bit of module level documentation in bezier -- then I will
add bezier to the API docs
 - for triple quoted docstrings, I would like to stick to the format::
 def myfunc(args):
 """"
 this is my docstring
 """"
 rather than
 def myfunc(args):
 """"this is my docstring
 """"
 - I renamed bezier_util to bezier (PEP8 style guide advises to avoid
underscores and make module names as short as is reasonable), and we
should import it with the full name "from matplotlib.bezier import
..." rather than "from bezier import ..."
 - 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.
These are of course mostly minor stylistic nits, but I want the code
to be as uniform as possible.
I've committed this to svn r6353, and updated the website, so you can
see your examples in the gallery and examples pages:
 http://matplotlib.sourceforge.net/gallery.html
 http://matplotlib.sourceforge.net/gallery.html
Very nice contribution!
JDH

Jae-Joon Lee wrote:
> I think it is a good idea to add such a feature in mpl, and I guess it
> would better to have some general way to provide backend specific
> options.
> 
Also note that this specific functionality isn't backend-specific. PDF 
files, for example, also have the ability to have clickable links. So 
any design we come up with should be seen as "general functionality 
which only some backends implement when the format supports it" rather 
than a "backend-specific hack". In this case, simply ignoring the url 
is a reasonable thing to do for backends that can't support it.
> Actually, I have been using a modified version of mpl which enables to
> set the individual ID of the patches (this is only meaningful in case
> of the svg backend) in a very similar way that Andrew described. The
> purpose of setting ID is to do some postprocessing of the resulting
> svg file. A small post about this can be found at
>
> http://abitofpythonabitofastronomy.blogspot.com/2008/10/svg.html
> 
This is a very cool example -- and presents another great feature to add 
in the future (filtering). Again, it's conceivable that future versions 
of PDF may have similar functionality, so we should think about generic 
ways to do it. But that's probably another discussion...
> And my approach was also to use GCs. Although I don't quite like this
> approach, it seems to be the easiest way because, as far as I know,
> the backends in mpl does not know about the artists.
> 
You're right, the high-level artists that are exposed to the end user of 
matplotlib are somewhat removed from the low-level graphics primitives 
that are passed to the backends, and that may be problematic. But 
adding this to the GC of an artist is the cleanest way I can think of to 
add these extra properties that need to be passed to the backends, as we 
wouldn't have to change the backend API.
Since the creation of the gc for each drawing call happens mainly in 
base classes (Patch, Text, Collection), there shouldn't be too many 
places to update to add these extra attributes to the gc. We could 
handle these new attributes in Artist.draw and have Patch.draw, 
Text.draw, Collection.draw etc. delegate to that to reduce code duplication.
> I think we may introduce a new dictionary property to the GC class and
> also in the Artist. And modifies draw() methods of Patch and others so
> that it use these properties to pass any optioanl information (
> "url"or "id") to the backends.
> 
Are you suggesting an extra dictionary in the gc to which arbitrary 
key/value pairs can be added? I don't like that very much. I think if 
we're going to support hyperlinks, we should create a true API for them 
that could be used across all backends (even if most backends can't 
support the functionality).
> But I'm not sure is if it is a good idea to expose this option (or
> "url" in the Andrew's original post) to the functions in the axes.py.
> We can just grab the return value of the "bar" command (which is a
> list of patches) and set some backend specific options for each
> patches.
> 
For the same reasons above, I don't see this as backend-specific, so I 
don't have a problem adding it as an Artist setter/kwarg that would be 
available on any method where Artist kwargs are supported. (And 
probably analogously have a list of urls for Collections).
In the specific case of bar(), one may still be forced to manually set 
urls on each Rectangle if one wants those urls to be different. But 
this is no different than the current situation wrt facecolor or any 
other attribute, since bar is not written on top of Collection.
Anyway, I like where this is going. I think this will be a great addition.
Cheers,
Mike
>
> On Wed, Oct 29, 2008 at 6:06 PM, Andrew Stock
> <mat...@an...> wrote:
> 
>> Hi,
>>
>> I have a requirement to make clickable bar charts using the SVG output
>> (rather than html maps).
>>
>> An initial look has suggested that the following changes would be required:
>>
>> backend_bases.py: Add a url property to GraphicsContextBase
>> (defaulting to None, so it's all backwards compatible)
>> axes.py: Add a url option to the bar function and pass this on to the
>> constructor of the Rectangle object
>> patches.py: Pass the url option in the constructor for the Patch
>> object to the GraphicsContextBase object created in the draw function
>> backends/backend_svg.py: Add check to _draw_svg_element for url set in
>> gc. If it is, write out SVG code for xlink.
>>
>> I can make these changes and (if people think it would be useful)
>> contribute the changes back. However, before I do this, I wanted to
>> check whether this is the right approach to take - I'm not experienced
>> with the internals of matplotlib and so if there's a better way of
>> doing it, I'd be grateful for the advice.
>>
>> Once I got the bar charts working, I would be interested in possibly
>> extending this to other chart types.
>>
>> Regards
>>
>> Andrew
>>
>> -------------------------------------------------------------------------
>> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Agreed. I think it is missing only be accident.
Mike
John Hunter wrote:
> On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <rm...@gm...> wrote:
>
> 
>> Here's probably a better question to ask than just to fix the example.
>> Was it intended that the Rectangle.xy attribute disappear? I couldn't
>> find it documented in API_CHANGES. It appears that there was just a
>> change at some point in Michael's transforms work. If it's considered
>> desirable to have it back, I'll volunteer to whip up a patch to make it
>> a property. If not, let's just make sure we document this in API_CHANGES.
>> 
>
> I have no problem with you adding it back in as a convenience
> property. Can't see the harm.
>
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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

Hello,
I have been putting some initial effort on implementing a new Legend
class which has paddings in canvas unit.
A related post is
http://www.mail-archive.com/mat...@li.../msg08560.html
My current implementation has a same functionality as the old one (an
example figure attached), but I haven't implemented a new features
like multicolumn option yet.
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.
One option I can think of is a work flow something like below.
 import matplotlib.legend
 matplotlib.legend.use_newclass(True) # this simply override the
rcParam with new default values and bind legend.Legend to the new
class.
 # do some stuff
 matplotlib.legend.use_newclass(False) # recover the original
rcParam and rebind legend.Legend back to the original class
So, how do others think?
Any idea or suggestion is welcomed.
Regards,
-JJ

I think it is a good idea to add such a feature in mpl, and I guess it
would better to have some general way to provide backend specific
options.
Actually, I have been using a modified version of mpl which enables to
set the individual ID of the patches (this is only meaningful in case
of the svg backend) in a very similar way that Andrew described. The
purpose of setting ID is to do some postprocessing of the resulting
svg file. A small post about this can be found at
http://abitofpythonabitofastronomy.blogspot.com/2008/10/svg.html
And my approach was also to use GCs. Although I don't quite like this
approach, it seems to be the easiest way because, as far as I know,
the backends in mpl does not know about the artists.
I think we may introduce a new dictionary property to the GC class and
also in the Artist. And modifies draw() methods of Patch and others so
that it use these properties to pass any optioanl information (
"url"or "id") to the backends.
But I'm not sure is if it is a good idea to expose this option (or
"url" in the Andrew's original post) to the functions in the axes.py.
We can just grab the return value of the "bar" command (which is a
list of patches) and set some backend specific options for each
patches.
Regards,
-JJ
On Wed, Oct 29, 2008 at 6:06 PM, Andrew Stock
<mat...@an...> wrote:
> Hi,
>
> I have a requirement to make clickable bar charts using the SVG output
> (rather than html maps).
>
> An initial look has suggested that the following changes would be required:
>
> backend_bases.py: Add a url property to GraphicsContextBase
> (defaulting to None, so it's all backwards compatible)
> axes.py: Add a url option to the bar function and pass this on to the
> constructor of the Rectangle object
> patches.py: Pass the url option in the constructor for the Patch
> object to the GraphicsContextBase object created in the draw function
> backends/backend_svg.py: Add check to _draw_svg_element for url set in
> gc. If it is, write out SVG code for xlink.
>
> I can make these changes and (if people think it would be useful)
> contribute the changes back. However, before I do this, I wanted to
> check whether this is the right approach to take - I'm not experienced
> with the internals of matplotlib and so if there's a better way of
> doing it, I'd be grateful for the advice.
>
> Once I got the bar charts working, I would be interested in possibly
> extending this to other chart types.
>
> Regards
>
> Andrew
>
> -------------------------------------------------------------------------
> 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
>

John and others,
I submitted a patch of the fancy arrow I mentioned a while ago.
http://sourceforge.net/tracker2/?func=detail&aid=2209021&group_id=80706&atid=560722
I kept my FancyArrowPatch as a separate class instead of merging it
with existing classes.
Instead, I modified the Annotation class so that it optionally uses
FancyArrowPatch.
A simple example usage is
 ax.annotate('test', xy=(0, 1), xycoords='data',
 xytext=(-50, 30), textcoords='offset points',
 arrowprops=dict(arrowstyle="->")
 )
FancyArrowPatch is used if arrowprops has a "arrowstyle" key, similar
to what I have done with FancyBox.
I added a new file "bezier_util.py" which includes some utility
functions. Maybe we may put some (or all) into path.py?
I also added a new example file "annotation_demo2.py".
The outputs of the example file are attached.
I'll appreciate if you review my patch.
Any comments or feedback is welcomed.
Regards,
-JJ

Hi,
I have a requirement to make clickable bar charts using the SVG output
(rather than html maps).
An initial look has suggested that the following changes would be required:
backend_bases.py: Add a url property to GraphicsContextBase
(defaulting to None, so it's all backwards compatible)
axes.py: Add a url option to the bar function and pass this on to the
constructor of the Rectangle object
patches.py: Pass the url option in the constructor for the Patch
object to the GraphicsContextBase object created in the draw function
backends/backend_svg.py: Add check to _draw_svg_element for url set in
gc. If it is, write out SVG code for xlink.
I can make these changes and (if people think it would be useful)
contribute the changes back. However, before I do this, I wanted to
check whether this is the right approach to take - I'm not experienced
with the internals of matplotlib and so if there's a better way of
doing it, I'd be grateful for the advice.
Once I got the bar charts working, I would be interested in possibly
extending this to other chart types.
Regards
Andrew

On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <rm...@gm...> wrote:
> Here's probably a better question to ask than just to fix the example.
> Was it intended that the Rectangle.xy attribute disappear? I couldn't
> find it documented in API_CHANGES. It appears that there was just a
> change at some point in Michael's transforms work. If it's considered
> desirable to have it back, I'll volunteer to whip up a patch to make it
> a property. If not, let's just make sure we document this in API_CHANGES.
I have no problem with you adding it back in as a convenience
property. Can't see the harm.
JDH

> Neil Crighton wrote:
>> I noticed on the event handling doc page:
>>
>> mat...@li...
>>
>> that the draggable rectangle example doesn't work in version 0.98.3.
>> The rectangle class no longer seems to have the xy property. If you
>> replace the current on_press() method in the example with the code
>> below it seem to work.
>>
>> def on_press(self, event):
>> 'on button press we will see if the mouse is over us and store
>> some data'
>> if event.inaxes != self.rect.axes: return
>>
>> contains, attrd = self.rect.contains(event)
>> if not contains: return
>> xy = self.rect.get_x(),self.rect.get_y()
>> print 'event contains', xy
>> x0, y0 = xy
>> self.press = x0, y0, event.xdata, event.ydata
>>
Here's probably a better question to ask than just to fix the example.
Was it intended that the Rectangle.xy attribute disappear? I couldn't
find it documented in API_CHANGES. It appears that there was just a
change at some point in Michael's transforms work. If it's considered
desirable to have it back, I'll volunteer to whip up a patch to make it
a property. If not, let's just make sure we document this in API_CHANGES.
My opinion is that randomly breaking API is always bad, and there's not
much effort involved in fixing it here. On the other hand, we've
already had 3 with this breakage, and no complaints up until now (and
that's from our own docs :P)
Thoughts?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Michiel de Hoon wrote:
> --- On Tue, 10/28/08, Christopher Barker <Chr...@no...>
> wrote:
>> I'm still curious where all this speed comes from.
> At this point, most of it is coming from having complete control over
> the event loop, which allows to avoid superfluous calls to draw().
well, what would be really nice is if we could figure out how to get rid 
of some of this superfluous calls to draw(0 in all the back-ends! I have 
noticed a bunch of extras in wxAgg, but had a hard time untangling it all.
Also, OS-X does double buffer itself, so there may be extra work being 
done there is other back-ends -- essentially triple buffering.
oh well.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi,
I attach a trivial patch to pass a weight argument through hist() to 
histogram().
Cheers,
Olle