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 <[EMAIL PROTECTED]> 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 > ------------------------------------------------------------------------- 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
