matplotlib-devel Mailing List for matplotlib (Page 5)

I went ahead and committed the latest version of your patch. Thanks. 
This is a cool new feature.
I think it's probably low-risk for having Windows problems, but having 
it in SVN will make it more likely for Windows users to test.
Cheers,
Mike
Andrew Stock wrote:
> Jae-Joon,
>
> Thanks for your comments. You have successfully found areas in my
> patch that were overcomplicated!
>
> I have attached a new patch which doesn't alter the api of draw_image
> and uses the im object as Jae-Joon suggests.
>
> I've tested this on Linux Python 2.5 as before, but not on Windows as
> I don't have the correct development environment set up at the moment.
>
> Regards
>
> Andrew
>
> On Fri, Nov 7, 2008 at 10:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
> 
>> Andrew,
>>
>> I just had a quick look at your patch.
>> I'm a bit distracted with your changes regarding the "url" support of the image.
>> Do we need to change the api of the draw_image()? Can we just utilize
>> "im" object as we did with the "gc"? Check the patch below. This
>> simple method seem to work fine for me.
>>
>> I also noted that, in the __init__() methods of the Patch and the
>> AxesImage class, you explicitly declare "url" as a keyword argument
>> and also initialize self.url. I don't think these are necessary as
>> "url" is already a property of the Artist class.
>>
>> IHTH,
>>
>> -JJ
>>
>>
>> Index: lib/matplotlib/image.py
>> ===================================================================
>> --- lib/matplotlib/image.py (revision 6361)
>> +++ lib/matplotlib/image.py (working copy)
>> @@ -234,6 +234,7 @@
>> self.axes.get_yscale() != 'linear'):
>> warnings.warn("Images are not supported on non-linear axes.")
>> im = self.make_image(renderer.get_image_magnification())
>> + im._url = self.get_url()
>> l, b, widthDisplay, heightDisplay = self.axes.bbox.bounds
>> renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
>> *self.get_transformed_clip_path_and_affine())
>> Index: lib/matplotlib/backends/backend_svg.py
>> ===================================================================
>> --- lib/matplotlib/backends/backend_svg.py (revision 6361)
>> +++ lib/matplotlib/backends/backend_svg.py (working copy)
>> @@ -274,6 +283,9 @@
>>
>> h,w = im.get_size_out()
>>
>> + url = im._url
>> + if url is not None:
>> + self._svgwriter.write('<a xlink:href="%s">' % url)
>> self._svgwriter.write (
>> '<image x="%f" y="%f" width="%f" height="%f" '
>> '%s xlink:href="'%(x/trans[0],
>> (self.height-y)/trans[3]-h, w, h, transstr)
>> @@ -298,6 +310,8 @@
>> self._svgwriter.write(filename)
>>
>> self._svgwriter.write('"/>\n')
>> + if url is not None:
>> + self._svgwriter.write('</a>')
>>
>> def draw_text(self, gc, x, y, s, prop, angle, ismath):
>> if ismath:
>>
>>
>>
>>
>> On Thu, Nov 6, 2008 at 11:40 AM, Andrew Stock
>> <mat...@an...> wrote:
>> 
>>> Thanks Michael,
>>>
>>> I've attached a new diff file which I believe also has all the
>>> necessary changes to the collections and images. I've also attached
>>> two simple scripts which test the collections and image functionality.
>>>
>>> I've had to make some modification to extension code in this patch
>>> which is definitely not my area of expertise so it would be worth
>>> someone more experienced casting an eye over this.
>>>
>>> I've tested this on Linux and successfully run the backend_driver.py
>>> file (or at least, it failed with the same errors as before I applied
>>> the patch!).
>>>
>>> Any other comments welcome
>>>
>>> Thanks
>>>
>>> On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <md...@st...> wrote:
>>> 
>>>> This looks great to me. I can confirm that this works on Linux as well.
>>>>
>>>> I think from here it's just a matter of applying the same pattern of changes
>>>> to collections and images. Once that's done, I'm happy to apply the patch.
>>>> And if you plan to make a lot of changes in the future, it generally pretty
>>>> easy to get commit access. Just ask.
>>>>
>>>> Mike
>>>>
>>>> Andrew Stock wrote:
>>>> 
>>>>> Hi,
>>>>>
>>>>> I've attached a diff file which implements the basic functionality. It
>>>>> currently doesn't handle collections or draw_image, but I wanted to
>>>>> get something simple working first, before expanding the scope. A
>>>>> simple test program is as follows:
>>>>>
>>>>> from pylab import *
>>>>>
>>>>> f = figure()
>>>>> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>>>>>
>>>>> a.set_url('http://www.google.com')
>>>>>
>>>>> f.canvas.print_figure(r'c:\test.svg')
>>>>>
>>>>> I'd be interested in comments / feedback on the attached before I
>>>>> start to branch out into more significant changes!
>>>>>
>>>>> Thanks
>>>>>
>>>>> Andrew
>>>>>
>>>>> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...>
>>>>> wrote:
>>>>>
>>>>> 
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>> 
>>> -------------------------------------------------------------------------
>>> 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

Jae-Joon,
Thanks for your comments. You have successfully found areas in my
patch that were overcomplicated!
I have attached a new patch which doesn't alter the api of draw_image
and uses the im object as Jae-Joon suggests.
I've tested this on Linux Python 2.5 as before, but not on Windows as
I don't have the correct development environment set up at the moment.
Regards
Andrew
On Fri, Nov 7, 2008 at 10:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Andrew,
>
> I just had a quick look at your patch.
> I'm a bit distracted with your changes regarding the "url" support of the image.
> Do we need to change the api of the draw_image()? Can we just utilize
> "im" object as we did with the "gc"? Check the patch below. This
> simple method seem to work fine for me.
>
> I also noted that, in the __init__() methods of the Patch and the
> AxesImage class, you explicitly declare "url" as a keyword argument
> and also initialize self.url. I don't think these are necessary as
> "url" is already a property of the Artist class.
>
> IHTH,
>
> -JJ
>
>
> Index: lib/matplotlib/image.py
> ===================================================================
> --- lib/matplotlib/image.py (revision 6361)
> +++ lib/matplotlib/image.py (working copy)
> @@ -234,6 +234,7 @@
> self.axes.get_yscale() != 'linear'):
> warnings.warn("Images are not supported on non-linear axes.")
> im = self.make_image(renderer.get_image_magnification())
> + im._url = self.get_url()
> l, b, widthDisplay, heightDisplay = self.axes.bbox.bounds
> renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
> *self.get_transformed_clip_path_and_affine())
> Index: lib/matplotlib/backends/backend_svg.py
> ===================================================================
> --- lib/matplotlib/backends/backend_svg.py (revision 6361)
> +++ lib/matplotlib/backends/backend_svg.py (working copy)
> @@ -274,6 +283,9 @@
>
> h,w = im.get_size_out()
>
> + url = im._url
> + if url is not None:
> + self._svgwriter.write('<a xlink:href="%s">' % url)
> self._svgwriter.write (
> '<image x="%f" y="%f" width="%f" height="%f" '
> '%s xlink:href="'%(x/trans[0],
> (self.height-y)/trans[3]-h, w, h, transstr)
> @@ -298,6 +310,8 @@
> self._svgwriter.write(filename)
>
> self._svgwriter.write('"/>\n')
> + if url is not None:
> + self._svgwriter.write('</a>')
>
> def draw_text(self, gc, x, y, s, prop, angle, ismath):
> if ismath:
>
>
>
>
> On Thu, Nov 6, 2008 at 11:40 AM, Andrew Stock
> <mat...@an...> wrote:
>> Thanks Michael,
>>
>> I've attached a new diff file which I believe also has all the
>> necessary changes to the collections and images. I've also attached
>> two simple scripts which test the collections and image functionality.
>>
>> I've had to make some modification to extension code in this patch
>> which is definitely not my area of expertise so it would be worth
>> someone more experienced casting an eye over this.
>>
>> I've tested this on Linux and successfully run the backend_driver.py
>> file (or at least, it failed with the same errors as before I applied
>> the patch!).
>>
>> Any other comments welcome
>>
>> Thanks
>>
>> On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <md...@st...> wrote:
>>> This looks great to me. I can confirm that this works on Linux as well.
>>>
>>> I think from here it's just a matter of applying the same pattern of changes
>>> to collections and images. Once that's done, I'm happy to apply the patch.
>>> And if you plan to make a lot of changes in the future, it generally pretty
>>> easy to get commit access. Just ask.
>>>
>>> Mike
>>>
>>> Andrew Stock wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've attached a diff file which implements the basic functionality. It
>>>> currently doesn't handle collections or draw_image, but I wanted to
>>>> get something simple working first, before expanding the scope. A
>>>> simple test program is as follows:
>>>>
>>>> from pylab import *
>>>>
>>>> f = figure()
>>>> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>>>>
>>>> a.set_url('http://www.google.com')
>>>>
>>>> f.canvas.print_figure(r'c:\test.svg')
>>>>
>>>> I'd be interested in comments / feedback on the attached before I
>>>> start to branch out into more significant changes!
>>>>
>>>> Thanks
>>>>
>>>> Andrew
>>>>
>>>> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...>
>>>> wrote:
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>

Andrew,
I just had a quick look at your patch.
I'm a bit distracted with your changes regarding the "url" support of the image.
Do we need to change the api of the draw_image()? Can we just utilize
"im" object as we did with the "gc"? Check the patch below. This
simple method seem to work fine for me.
I also noted that, in the __init__() methods of the Patch and the
AxesImage class, you explicitly declare "url" as a keyword argument
and also initialize self.url. I don't think these are necessary as
"url" is already a property of the Artist class.
IHTH,
-JJ
Index: lib/matplotlib/image.py
===================================================================
--- lib/matplotlib/image.py	(revision 6361)
+++ lib/matplotlib/image.py	(working copy)
@@ -234,6 +234,7 @@
 self.axes.get_yscale() != 'linear'):
 warnings.warn("Images are not supported on non-linear axes.")
 im = self.make_image(renderer.get_image_magnification())
+ im._url = self.get_url()
 l, b, widthDisplay, heightDisplay = self.axes.bbox.bounds
 renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
 *self.get_transformed_clip_path_and_affine())
Index: lib/matplotlib/backends/backend_svg.py
===================================================================
--- lib/matplotlib/backends/backend_svg.py	(revision 6361)
+++ lib/matplotlib/backends/backend_svg.py	(working copy)
@@ -274,6 +283,9 @@
 h,w = im.get_size_out()
+ url = im._url
+ if url is not None:
+ self._svgwriter.write('<a xlink:href="%s">' % url)
 self._svgwriter.write (
 '<image x="%f" y="%f" width="%f" height="%f" '
 '%s xlink:href="'%(x/trans[0],
(self.height-y)/trans[3]-h, w, h, transstr)
@@ -298,6 +310,8 @@
 self._svgwriter.write(filename)
 self._svgwriter.write('"/>\n')
+ if url is not None:
+ self._svgwriter.write('</a>')
 def draw_text(self, gc, x, y, s, prop, angle, ismath):
 if ismath:
On Thu, Nov 6, 2008 at 11:40 AM, Andrew Stock
<mat...@an...> wrote:
> Thanks Michael,
>
> I've attached a new diff file which I believe also has all the
> necessary changes to the collections and images. I've also attached
> two simple scripts which test the collections and image functionality.
>
> I've had to make some modification to extension code in this patch
> which is definitely not my area of expertise so it would be worth
> someone more experienced casting an eye over this.
>
> I've tested this on Linux and successfully run the backend_driver.py
> file (or at least, it failed with the same errors as before I applied
> the patch!).
>
> Any other comments welcome
>
> Thanks
>
> On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <md...@st...> wrote:
>> This looks great to me. I can confirm that this works on Linux as well.
>>
>> I think from here it's just a matter of applying the same pattern of changes
>> to collections and images. Once that's done, I'm happy to apply the patch.
>> And if you plan to make a lot of changes in the future, it generally pretty
>> easy to get commit access. Just ask.
>>
>> Mike
>>
>> Andrew Stock wrote:
>>>
>>> Hi,
>>>
>>> I've attached a diff file which implements the basic functionality. It
>>> currently doesn't handle collections or draw_image, but I wanted to
>>> get something simple working first, before expanding the scope. A
>>> simple test program is as follows:
>>>
>>> from pylab import *
>>>
>>> f = figure()
>>> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>>>
>>> a.set_url('http://www.google.com')
>>>
>>> f.canvas.print_figure(r'c:\test.svg')
>>>
>>> I'd be interested in comments / feedback on the attached before I
>>> start to branch out into more significant changes!
>>>
>>> Thanks
>>>
>>> Andrew
>>>
>>> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...>
>>> wrote:
>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>
> -------------------------------------------------------------------------
> 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
>
>

Thanks Michael,
I've attached a new diff file which I believe also has all the
necessary changes to the collections and images. I've also attached
two simple scripts which test the collections and image functionality.
I've had to make some modification to extension code in this patch
which is definitely not my area of expertise so it would be worth
someone more experienced casting an eye over this.
I've tested this on Linux and successfully run the backend_driver.py
file (or at least, it failed with the same errors as before I applied
the patch!).
Any other comments welcome
Thanks
On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <md...@st...> wrote:
> This looks great to me. I can confirm that this works on Linux as well.
>
> I think from here it's just a matter of applying the same pattern of changes
> to collections and images. Once that's done, I'm happy to apply the patch.
> And if you plan to make a lot of changes in the future, it generally pretty
> easy to get commit access. Just ask.
>
> Mike
>
> Andrew Stock wrote:
>>
>> Hi,
>>
>> I've attached a diff file which implements the basic functionality. It
>> currently doesn't handle collections or draw_image, but I wanted to
>> get something simple working first, before expanding the scope. A
>> simple test program is as follows:
>>
>> from pylab import *
>>
>> f = figure()
>> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>>
>> a.set_url('http://www.google.com')
>>
>> f.canvas.print_figure(r'c:\test.svg')
>>
>> I'd be interested in comments / feedback on the attached before I
>> start to branch out into more significant changes!
>>
>> Thanks
>>
>> Andrew
>>
>> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...>
>> wrote:
>>
>>>
>>> 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
>>>
>>>
>>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

David Kaplan wrote:
> Hi,
>
> On Wed, 2008年11月05日 at 11:58 -0500, Michael Droettboom wrote:
> 
>> What is the argument against? It seems like this would be 
>> straightforward (at least from the outside). But I'm probably
>> missing 
>> something.
>> 
>
> More work for diminishing interest.... Perhaps I am incorrect, but I
> think this object is only used for legends and axes labels, which
> probably wouldn't use this feature. 
>
> If I remember correctly, there was also the problem that the dash had
> its own rotation angle, which would require a whole other set of
> corresponding variables and methods to select the coordinate system for
> the dash.... 
>
> I think I saw this and just decided to raise not implemented warnings on
> attempts to set non-screen coordinate system rotations.
>
> Is there a strong desire for adding this feature to text with dash?
> 
Thanks. I see the complications now. I agree -- let's not worry about 
TextWithDash for now, except for possibly warning or throwing when 
trying to use this new feature with a TextWithDash.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
On Wed, 2008年11月05日 at 13:28 -0500, Stan West wrote:
> Beyond the two options of the screen coordinates and the data
> coordinates as the references, I
> believe it would be useful to allow other coordinate systems. If I
> wanted to diagonally
> watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it
> would be convenient to
> specify a rotation of +/- 45 degrees relative to the normalized (0-1)
> figure coordinates. The
> watermark would lie along the diagonal regardless of the aspect ratio.
> Likewise, to watermark
> only a subplot, one might use the normalized axes coordinates. It
> seems especially convenient
> if users could accomplish that by passing to the text object one of
> the predefined transforms --
> like ax.transData, fig.transFigure, or ax.transAxes -- to specify the
> coordinate system for the
> rotation.
> 
> Would it be possible to specify the reference system and rotation
> angle in a composite transform
> using transform machinery such as rotate_deg or rotate_deg_around?
> 
This is an interesting suggestion, but seems like it is (a) a bit out of
my league and (b) like it would bring up other issues, such as which
coordinate system to use for interpreting the location given to the text
function for the text object. 
The standard way this problem has been dealt with is to create an
invisible axes that covers your entire plot and add a text object to
that axes. Can this method do the trick for you?
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,
On Wed, 2008年11月05日 at 11:58 -0500, Michael Droettboom wrote:
> What is the argument against? It seems like this would be 
> straightforward (at least from the outside). But I'm probably
> missing 
> something.
More work for diminishing interest.... Perhaps I am incorrect, but I
think this object is only used for legends and axes labels, which
probably wouldn't use this feature. 
If I remember correctly, there was also the problem that the dash had
its own rotation angle, which would require a whole other set of
corresponding variables and methods to select the coordinate system for
the dash.... 
I think I saw this and just decided to raise not implemented warnings on
attempts to set non-screen coordinate system rotations.
Is there a strong desire for adding this feature to text with dash?
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Wed, Nov 5, 2008 at 4:55 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> How much freedom would I (and my colleague) have in changing up some of
> the behavior/API of mlab.psd? My current issues with the function:
>
> 1) Returning one-sided or two-sided depends on whether the data is
> complex. I'd like that to be controlled by a keyword parameter (could
> take strings, such as 'two-sided' like matlab)
Sounds good
>
> 2) We'd like to add a parameter to control how many points are used for
> performing the FFT (automatic zero padding for increased plotting
> detail). The obvious name for this would be nfft, but this seems to
> conflict with the NFFT parameter. NFFT, confusingly, is used to specify
> the blocksize used for averaging. If we can't outright change names
> here, I'd love for suggestions on a good way forward.
I wrote this function a *long* time ago, so my memory is a little
hazy, but I don't find the terminology confusing. The method breaks
the sequence into NFFT sized chunks and does an fft on each NFFT
length piece, so that is the length of the fft. Perhaps an addition
pad argument if you want to zero pad the chunks?
I intended to replicate the matlab function when I wrote this, and
vaguely recall that I did some close comparisons on the output, but if
I am misusing this parameter let me know. Some (possibly dated)
matlab docs are here:
http://www.mathworks.com/access/helpdesk/help/toolbox/signal/index.html?/access/helpdesk/help/toolbox/signal/periodogram.html
> 3) Can we remove the requirement for even NFFT (blocksize)?
Sure
A while back someone on the list said that the amplitude scaling for
psd was of, but I never delved into it. Something you may want to
check into while you are poking around in there.
http://www.nabble.com/forum/Search.jtp?forum=2906&local=y&query=psd+amplitude
JDH

Hi,
How much freedom would I (and my colleague) have in changing up some of
the behavior/API of mlab.psd? My current issues with the function:
1) Returning one-sided or two-sided depends on whether the data is
complex. I'd like that to be controlled by a keyword parameter (could
take strings, such as 'two-sided' like matlab)
2) We'd like to add a parameter to control how many points are used for
performing the FFT (automatic zero padding for increased plotting
detail). The obvious name for this would be nfft, but this seems to
conflict with the NFFT parameter. NFFT, confusingly, is used to specify
 the blocksize used for averaging. If we can't outright change names
here, I'd love for suggestions on a good way forward.
3) Can we remove the requirement for even NFFT (blocksize)?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

> From: Michael Droettboom [mailto:md...@st...] 
> Sent: Wednesday, November 05, 2008 11:59
> 
> David Kaplan wrote:
> > Hi,
> >
> > Actually your question is a good one. One of the reasons I never
> > finished adding an option to text objects to rotate with respect to the
> > plot (is this the correct terminology?), not the screen, is that I
> > wasn't sure of the best way to implement this without making it
> > hopelessly confusing for the user. 
> >
> > One way is to add a boolean that tells the text object whether or not
> > the angle is with respect to screen coordinates. In this case,
> > text_obj.get_rotation() would return the angle in whichever coordinate
> > system is the active one based on the boolean, unless an option to
> > get_rotation is specified that would force the angle to the screen
> > coordinate system (this option would then be used by show methods to
> > assure they get the correct angle for plotting on the screen).
> > Similarly, set_rotation would set the angle in the active system. The
> > disadvantage of this approach is that it can be pretty confusing -
> > unless you consult the boolean, you don't know what your angle is
> > measured relative to.
> >
> > Another approach would be to add a ._rotationPlot variable, as well
> > as .get_rotationPlot and .set_rotationPlot text-object methods. In this
> > case, using set_rotation would set the "active" angle to be the screen
> > angle, while using set_rotationPlot would set the "active" angle to be
> > the plot angle. The non-active angle would be set to None and show
> > calls would test for whether or not ._rotation is none, in which case
> > the screen angle would be calculated from the transform. In this case,
> > get_rotation and get_rotationPlot would return angles in the respective
> > system, regardless of which one is "active".
> >
> > What structure would people prefer?
> > 
> I think the latter choice presents less confusion, particularly after 
> hearing your arguments. It should probably be rotation_plot, just to be 
> consistent with other getters/setters. There should probably also be a 
> check and warning for setting rotation_plot for figure text, where it 
> doesn't make sense, and fall back to the identity transform.
Beyond the two options of the screen coordinates and the data coordinates as the references, I
believe it would be useful to allow other coordinate systems. If I wanted to diagonally
watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it would be convenient to
specify a rotation of +/- 45 degrees relative to the normalized (0-1) figure coordinates. The
watermark would lie along the diagonal regardless of the aspect ratio. Likewise, to watermark
only a subplot, one might use the normalized axes coordinates. It seems especially convenient
if users could accomplish that by passing to the text object one of the predefined transforms --
like ax.transData, fig.transFigure, or ax.transAxes -- to specify the coordinate system for the
rotation.
Would it be possible to specify the reference system and rotation angle in a composite transform
using transform machinery such as rotate_deg or rotate_deg_around?
> > Another reason I never finished this is that I got confused by some of
> > the code - there was talk of unitful and unitless rotations and
> > coordinates. 
> Hopefully someone else has some guidance on unit-related issues. I 
> still don't have my head around that stuff.
> > Also, I wasn't sure what to do with objects that inherit
> > the text object class - namely, text with a dash. It didn't seem it was
> > worth adding this non-screen rotation functionality to these objects. 
> > 
> What is the argument against? It seems like this would be 
> straightforward (at least from the outside). But I'm probably missing 
> something.
> > If anyone can point me in the right direction on these points, I will
> > try to finish a patch for this functionality.
> > 
> Thanks.
> 
> Mike
> > Cheers,
> > David
> >
> > On Wed, 2008年11月05日 at 10:28 -0500, Michael Droettboom wrote:
> > 
> >> Darn clogged e-mail queue! ;)
> >>
> >> I see you've already addressed my question...
> >>
> >> Cheers,
> >> Mike
> >>
> >> David Kaplan wrote:
> >> 
> >>> Hi,
> >>>
> >>> I just wanted to send a note saying that I committed an additional
> >>> method to the Transforms class that transforms angles. The basic idea
> >>> is to transform an angle at a point to a new angle at the corresponding
> >>> point in the transformed coordinate system. The included method is
> >>> generic and should work well for almost any transform provided that the
> >>> spatial scale isn't too small or too large. Much faster algorithms that
> >>> would work regardless of spatial scale can be found for particular
> >>> transforms, particularly affine transforms, but I haven't added these
> >>> yet.
> >>>
> >>> I also added an example script that shows how to use this method to plot
> >>> text rotated so that it aligns with a line in a figure
> >>> ( text_rotation_relative_to_line.py ). 
> >>>
> >>> I initially intended to use this method to give text objects the option
> >>> to be rotated with respect to the plot coordinate system (as opposed to
> >>> the screen coordinate system), but I haven't gotten around to finishing
> >>> this yet.
> >>>
> >>> Cheers,
> >>> David
> >>>
> >>>
> >>> 
> >>> 
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
Stan

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.
Done in r6366. Also reverted the changes to the exercise, as the
description still mentioned using the xy attribute.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

David Kaplan wrote:
> Hi,
>
> Actually your question is a good one. One of the reasons I never
> finished adding an option to text objects to rotate with respect to the
> plot (is this the correct terminology?), not the screen, is that I
> wasn't sure of the best way to implement this without making it
> hopelessly confusing for the user. 
>
> One way is to add a boolean that tells the text object whether or not
> the angle is with respect to screen coordinates. In this case,
> text_obj.get_rotation() would return the angle in whichever coordinate
> system is the active one based on the boolean, unless an option to
> get_rotation is specified that would force the angle to the screen
> coordinate system (this option would then be used by show methods to
> assure they get the correct angle for plotting on the screen).
> Similarly, set_rotation would set the angle in the active system. The
> disadvantage of this approach is that it can be pretty confusing -
> unless you consult the boolean, you don't know what your angle is
> measured relative to.
>
> Another approach would be to add a ._rotationPlot variable, as well
> as .get_rotationPlot and .set_rotationPlot text-object methods. In this
> case, using set_rotation would set the "active" angle to be the screen
> angle, while using set_rotationPlot would set the "active" angle to be
> the plot angle. The non-active angle would be set to None and show
> calls would test for whether or not ._rotation is none, in which case
> the screen angle would be calculated from the transform. In this case,
> get_rotation and get_rotationPlot would return angles in the respective
> system, regardless of which one is "active".
>
> What structure would people prefer?
> 
I think the latter choice presents less confusion, particularly after 
hearing your arguments. It should probably be rotation_plot, just to be 
consistent with other getters/setters. There should probably also be a 
check and warning for setting rotation_plot for figure text, where it 
doesn't make sense, and fall back to the identity transform.
> Another reason I never finished this is that I got confused by some of
> the code - there was talk of unitful and unitless rotations and
> coordinates. 
Hopefully someone else has some guidance on unit-related issues. I 
still don't have my head around that stuff.
> Also, I wasn't sure what to do with objects that inherit
> the text object class - namely, text with a dash. It didn't seem it was
> worth adding this non-screen rotation functionality to these objects. 
> 
What is the argument against? It seems like this would be 
straightforward (at least from the outside). But I'm probably missing 
something.
> If anyone can point me in the right direction on these points, I will
> try to finish a patch for this functionality.
> 
Thanks.
Mike
> Cheers,
> David
>
> On Wed, 2008年11月05日 at 10:28 -0500, Michael Droettboom wrote:
> 
>> Darn clogged e-mail queue! ;)
>>
>> I see you've already addressed my question...
>>
>> Cheers,
>> Mike
>>
>> David Kaplan wrote:
>> 
>>> Hi,
>>>
>>> I just wanted to send a note saying that I committed an additional
>>> method to the Transforms class that transforms angles. The basic idea
>>> is to transform an angle at a point to a new angle at the corresponding
>>> point in the transformed coordinate system. The included method is
>>> generic and should work well for almost any transform provided that the
>>> spatial scale isn't too small or too large. Much faster algorithms that
>>> would work regardless of spatial scale can be found for particular
>>> transforms, particularly affine transforms, but I haven't added these
>>> yet.
>>>
>>> I also added an example script that shows how to use this method to plot
>>> text rotated so that it aligns with a line in a figure
>>> ( text_rotation_relative_to_line.py ). 
>>>
>>> I initially intended to use this method to give text objects the option
>>> to be rotated with respect to the plot coordinate system (as opposed to
>>> the screen coordinate system), but I haven't gotten around to finishing
>>> this yet.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> 
>>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

From: Darren Dale [mailto:dsd...@gm...] 
Sent: Wednesday, November 05, 2008 08:48
On Tuesday 04 November 2008 05:23:19 pm you wrote:
> I attempted to improve the dependency checking in matplotlib.__init__,
> using the subprocess module to silence some deprecation warnings
> encountered with py2.6. I dont have access to a Windows machine, would
> someone please test the attached patch or __init__.py file to see if it
> works on that platform?
>
> Thanks,
> Darren
>
>
> Do you need it tested with Python 2.5 or 2.6?
2.4 through 2.6.
I'm in the process of replacing my laptop, so I should be able to check it myself on Vista in
two weeks.
With Python 2.5 in XP, I ran a cursory check and saw no problem initializing and using
matplotlib with your __init__.py. As for the other Python versions, I'm afraid that I have
neither of them installed.

Hi,
Actually your question is a good one. One of the reasons I never
finished adding an option to text objects to rotate with respect to the
plot (is this the correct terminology?), not the screen, is that I
wasn't sure of the best way to implement this without making it
hopelessly confusing for the user. 
One way is to add a boolean that tells the text object whether or not
the angle is with respect to screen coordinates. In this case,
text_obj.get_rotation() would return the angle in whichever coordinate
system is the active one based on the boolean, unless an option to
get_rotation is specified that would force the angle to the screen
coordinate system (this option would then be used by show methods to
assure they get the correct angle for plotting on the screen).
Similarly, set_rotation would set the angle in the active system. The
disadvantage of this approach is that it can be pretty confusing -
unless you consult the boolean, you don't know what your angle is
measured relative to.
Another approach would be to add a ._rotationPlot variable, as well
as .get_rotationPlot and .set_rotationPlot text-object methods. In this
case, using set_rotation would set the "active" angle to be the screen
angle, while using set_rotationPlot would set the "active" angle to be
the plot angle. The non-active angle would be set to None and show
calls would test for whether or not ._rotation is none, in which case
the screen angle would be calculated from the transform. In this case,
get_rotation and get_rotationPlot would return angles in the respective
system, regardless of which one is "active".
What structure would people prefer?
Another reason I never finished this is that I got confused by some of
the code - there was talk of unitful and unitless rotations and
coordinates. Also, I wasn't sure what to do with objects that inherit
the text object class - namely, text with a dash. It didn't seem it was
worth adding this non-screen rotation functionality to these objects. 
If anyone can point me in the right direction on these points, I will
try to finish a patch for this functionality.
Cheers,
David
On Wed, 2008年11月05日 at 10:28 -0500, Michael Droettboom wrote:
> Darn clogged e-mail queue! ;)
> 
> I see you've already addressed my question...
> 
> Cheers,
> Mike
> 
> David Kaplan wrote:
> > Hi,
> >
> > I just wanted to send a note saying that I committed an additional
> > method to the Transforms class that transforms angles. The basic idea
> > is to transform an angle at a point to a new angle at the corresponding
> > point in the transformed coordinate system. The included method is
> > generic and should work well for almost any transform provided that the
> > spatial scale isn't too small or too large. Much faster algorithms that
> > would work regardless of spatial scale can be found for particular
> > transforms, particularly affine transforms, but I haven't added these
> > yet.
> >
> > I also added an example script that shows how to use this method to plot
> > text rotated so that it aligns with a line in a figure
> > ( text_rotation_relative_to_line.py ). 
> >
> > I initially intended to use this method to give text objects the option
> > to be rotated with respect to the plot coordinate system (as opposed to
> > the screen coordinate system), but I haven't gotten around to finishing
> > this yet.
> >
> > Cheers,
> > David
> >
> >
> > 
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Darn clogged e-mail queue! ;)
I see you've already addressed my question...
Cheers,
Mike
David Kaplan wrote:
> Hi,
>
> I just wanted to send a note saying that I committed an additional
> method to the Transforms class that transforms angles. The basic idea
> is to transform an angle at a point to a new angle at the corresponding
> point in the transformed coordinate system. The included method is
> generic and should work well for almost any transform provided that the
> spatial scale isn't too small or too large. Much faster algorithms that
> would work regardless of spatial scale can be found for particular
> transforms, particularly affine transforms, but I haven't added these
> yet.
>
> I also added an example script that shows how to use this method to plot
> text rotated so that it aligns with a line in a figure
> ( text_rotation_relative_to_line.py ). 
>
> I initially intended to use this method to give text objects the option
> to be rotated with respect to the plot coordinate system (as opposed to
> the screen coordinate system), but I haven't gotten around to finishing
> this yet.
>
> Cheers,
> David
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I just wanted to send a note saying that I committed an additional
method to the Transforms class that transforms angles. The basic idea
is to transform an angle at a point to a new angle at the corresponding
point in the transformed coordinate system. The included method is
generic and should work well for almost any transform provided that the
spatial scale isn't too small or too large. Much faster algorithms that
would work regardless of spatial scale can be found for particular
transforms, particularly affine transforms, but I haven't added these
yet.
I also added an example script that shows how to use this method to plot
text rotated so that it aligns with a line in a figure
( text_rotation_relative_to_line.py ). 
I initially intended to use this method to give text objects the option
to be rotated with respect to the plot coordinate system (as opposed to
the screen coordinate system), but I haven't gotten around to finishing
this yet.
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Thanks, David. That's a much-needed feature.
However, wouldn't it be simpler, API-wise, to add a new kwarg 
"rotation_data" (or some better name) which would be an angle in data 
space? (Or alternatively a boolean flag "rotation_in_data_coords"). 
The other advantage of that approach is that since the Text object knows 
what the "purpose" of the angle is, it could update the angle when the 
limits or figure size are changed.
It looks like the heavy lifting of the calculation is already there...
Cheers,
Mike
dmk...@us... wrote:
> Revision: 6363
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6363&view=rev
> Author: dmkaplan
> Date: 2008年11月05日 14:43:29 +0000 (2008年11月05日)
>
> Log Message:
> -----------
> Adding a small script that demonstrates the utility of transform_angles method added in last
> commit (from dmkaplan).
>
> Added Paths:
> -----------
> trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
>
> Added: trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
> ===================================================================
> --- trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py	 (rev 0)
> +++ trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py	2008年11月05日 14:43:29 UTC (rev 6363)
> @@ -0,0 +1,36 @@
> +#!/usr/bin/env python
> +"""
> +Text objects in matplotlib are normally rotated with respect to the
> +screen coordinate system (i.e., 45 degrees rotation plots text along a
> +line that is inbetween horizontal and vertical no matter how the axes
> +are changed). However, at times one wants to rotate text with respect
> +to something on the plot. In this case, the correct angle won't be
> +the angle of that object in the plot coordinate system, but the angle
> +that that object APPEARS in the screen coordinate system. This angle
> +is found by transforming the angle from the plot to the screen
> +coordinate system, as shown in the example below.
> +"""
> +from pylab import *
> +
> +# Plot diagonal line (45 degrees)
> +h = plot( r_[:10], r_[:10] )
> +
> +# set limits so that it no longer looks on screen to be 45 degrees
> +xlim([-10,20])
> +
> +# Locations to plot text
> +l1 = array((1,1))
> +l2 = array((5,5))
> +
> +# Rotate angle
> +angle = 45
> +trans_angle = gca().transData.transform_angles(array((45,)),
> + l2.reshape((1,2)))[0]
> +
> +# Plot text
> +th1 = text(l1[0],l1[1],'text not rotated correctly',fontsize=16,
> + rotation=angle)
> +th2 = text(l2[0],l2[1],'text not rotated correctly',fontsize=16,
> + rotation=trans_angle)
> +
> +show()
>
>
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>
> -------------------------------------------------------------------------
> 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-checkins mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This looks great to me. I can confirm that this works on Linux as well.
I think from here it's just a matter of applying the same pattern of 
changes to collections and images. Once that's done, I'm happy to apply 
the patch. And if you plan to make a lot of changes in the future, it 
generally pretty easy to get commit access. Just ask.
Mike
Andrew Stock wrote:
> Hi,
>
> I've attached a diff file which implements the basic functionality. It
> currently doesn't handle collections or draw_image, but I wanted to
> get something simple working first, before expanding the scope. A
> simple test program is as follows:
>
> from pylab import *
>
> f = figure()
> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>
> a.set_url('http://www.google.com')
>
> f.canvas.print_figure(r'c:\test.svg')
>
> I'd be interested in comments / feedback on the attached before I
> start to branch out into more significant changes!
>
> Thanks
>
> Andrew
>
> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...> wrote:
> 
>> 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
>>
>>
>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tuesday 04 November 2008 05:23:19 pm you wrote:
> I attempted to improve the dependency checking in matplotlib.__init__,
> using the subprocess module to silence some deprecation warnings
> encountered with py2.6. I dont have access to a Windows machine, would
> someone please test the attached patch or __init__.py file to see if it
> works on that platform?
>
> Thanks,
> Darren
>
>
> Do you need it tested with Python 2.5 or 2.6?
2.4 through 2.6.
I'm in the process of replacing my laptop, so I should be able to check it 
myself on Vista in two weeks.

Hi,
I've attached a diff file which implements the basic functionality. It
currently doesn't handle collections or draw_image, but I wanted to
get something simple working first, before expanding the scope. A
simple test program is as follows:
from pylab import *
f = figure()
a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
a.set_url('http://www.google.com')
f.canvas.print_figure(r'c:\test.svg')
I'd be interested in comments / feedback on the attached before I
start to branch out into more significant changes!
Thanks
Andrew
On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <md...@st...> wrote:
> 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
>
>

I attempted to improve the dependency checking in matplotlib.__init__, using the subprocess
module to silence some deprecation warnings encountered with py2.6. I dont have access to a
Windows machine, would someone please test the attached patch or __init__.py file to see if it
works on that platform?
 
Thanks,
Darren
 
Do you need it tested with Python 2.5 or 2.6?

*re-reads email*
Apparently it won't teach me.
Sorry for the spam.
2008年11月3日 Neil Crighton <nei...@gm...>:
> Thanks - sorry for posting the mailing list address instead of the the
> event handling page(!). That'll teach me to email before
> proof-reading...
>
> 2008年10月29日 Ryan May <rm...@gm...>:
>> 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
>>>
>>
>> Good catch. I checked in a slightly different version of the fix.
>>
>> Ryan
>>
>> --
>> Ryan May
>> Graduate Research Assistant
>> School of Meteorology
>> University of Oklahoma
>>
>

Thanks - sorry for posting the mailing list address instead of the the
event handling page(!). That'll teach me to email before
proof-reading...
2008年10月29日 Ryan May <rm...@gm...>:
> 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
>>
>
> Good catch. I checked in a slightly different version of the fix.
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>

On Sat, Nov 1, 2008 at 5:37 AM, Sandro Tosi <mo...@de...> wrote:
> Hello guys!
> Following up the discussion Benjiamin and me had about a couple of
> bugs in Ubuntu[1] and Debian[2], and what Mike wrote on [1], we'd like
> to explore the possibility for you to develop a "backend=Auto" mode,
> that can discover automatically at runtime the backend to use from the
> ones available (in case of multiple backends, let's use a priority
> list [gtk, qt, tk, ...]).
This should be fairly easy to implement -- we already do something
like this at build time when we choose the default backend to put into
the template. FYI, since you are a packager, I jwant to clarify what
happens at build time. We have a file called setup.cfg.template which
is a template for people who want to override the default behavior.
You can copy this to setup.cfg and choose what default backend you
want, and the setup program will create an rc configured accordingly.
But if someone has not done this, the setup script will look (at build
time) for gtk, wx, and tk, and set the backend in order of increasing
preference: Agg, TkAgg, WXAgg, GTKAgg. The file matplotlibrc.template
is then used to generate the default matplotlibrc, with this backend
selected. This matplotlibrc is installed to matplotlib/mpl-data/ and
is used as the default config if the user does not override it.
As a debian/ubuntu packager, you will probably want to use setup.cfg
and set your backend manually. You may want to use TkAgg since in
some ways this is the simplest backend to use in the most contexts,
primarily because it does not require special threading calls to work
interactively in the python shell -- see
http://matplotlib.sf.net/installing.html
But an "Auto" feature would be useful in other contexts too. One area
is when matplotlib is embedded in a GUI IDE matlab-like application.
There are several of these that are being worked on in different user
interfaces, primarily using the new embeddable ipython, and the
concern there is that the user may be using one application which
embeds a python shell, and when users import pylab in that shell, the
ought not to have to think: "now I am using python in a wx app, so I
need to sert wxagg" but in other scenarios, "now I am using pylab in a
plain python shell so use tkagg"
The auto search algorithm should go something like the following:
* if tkinter, wx, gtk or qt has already been imported in sys.modules,
use that backend - Gael has already an implementation in the pyplot
module using the rc param 'backend_fallback'
 * if backend = 'auto': try in order of preference :tkagg (most
likely to work in most contexts), gtkagg, wxagg, qtagg. This order
could easily be configurable
 * if none of the UIs are available in 'auto' mode, issue a warning
and set 'agg'
If I were packaging for ubuntu, I would select tkagg as the default,
so you don't have to wade into the GNOME vs KDE arena and because it
works out of the box in the most contexts and is a pretty small
dependency. You could modify the matplotlib runtime so that when the
.matplotlib directory is created (the first time mpl is run) it issues
a message like
 Creating config directory ~/.matplotlib. The default user interface
toolkit for matplotlib is TkInter via the "TkAgg backend" (see
 http://matplotlib.sourceforge.net/faq/installing_faq.html#id1). You
use other backends, you will need to install additional ubuntu
dependencies.
 For GTKAgg, install python-gtk, for WXAgg, install python-wxgtk, etc..."
> Personally, I think we can even attack the problem with a different
> solution: continue to ship all the mpl file in the "main" package
> (python-matplotlib in Debian & Ubuntu) and then create some "dummy"
> packages that simply depends on the python gui bindings (let's call
> them python-matplotlib-<ui>), each of them providing a virtual
> package, let's call it python-matplotlib-backend. If python-matplotlib
> depends on python-matplotlib-gtk OR python-matplotlib-backend, any
> backend installed can satisfy that dependency (and the default being
> gtk).
That should work fine, but I advise installing all of mpl and use
these dummies only for dependencies.
> Both of them has cons: the first poses problem to us for the
> packaging, and both does not solve the problem of not choosing a
> default (or requiring to specify another package (the backend chosen)
> when installing python-matplotlib); moreover, what other packages
> depending on python-matplotlib should do after this change (they
> expect mpl to Just Work)?
Well, if the package that depends on mpl requires for example wx and
the wx backend, then it is enough for them to get a full mpl install
and handle the wx dependency in their package. They would need to
make sure that the right mpl backend is selected when they import mpl,
but they can do that with the use directive.
> Another solution (that would save the most of the current work done),
> almost the same currently used today is: keep doing the same thing as
> of now, but do not install any python gui bindings, but popup a
> windows at python-matplotlib install time to ask the user what binding
> to use (then create the ad-hoc /etc/matplotlirc file with that
> "backend" set) and then ask to install the correct python binding for
> the backend chosen. A light version is: keep choosing gtk as default
> backend, and clearly document (even at install time) how to change
> backend.
This is in line with what I was suggesting, though I was suggesting it
at mpl first run time. Either way could work.
I do see that this is a problem: a colleague of mine with a new ubuntu
8.10 box installed python-matplotlib as one of his first packages, and
it brought in 280 MB of packages, including several UI toolkits and a
full tex distribution. I think the packagers are being over
inclusive. For optional dependencies like usetex, which most people
do not use, and optional backends, it would be better to have a clear
set of instructions for users who want these optional features to
simply apt-get install the optional dependencies themselves.
JDH

I attempted to improve the dependency checking in matplotlib.__init__, using 
the subprocess module to silence some deprecation warnings encountered with 
py2.6. I dont have access to a Windows machine, would someone please test the 
attached patch or __init__.py file to see if it works on that platform?
Thanks,
Darren