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
> Matplotlib-devel@lists.sourceforge.net
> 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


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to