Jae-Joon Lee wrote:
> I think it is a good idea to add such a feature in mpl, and I guess it
> would better to have some general way to provide backend specific
> options.
>   
Also note that this specific functionality isn't backend-specific.  PDF 
files, for example, also have the ability to have clickable links.  So 
any design we come up with should be seen as "general functionality 
which only some backends implement when the format supports it" rather 
than a "backend-specific hack".  In this case, simply ignoring the url 
is a reasonable thing to do for backends that can't support it.
> Actually, I have been using a modified version of mpl which enables to
> set the individual ID of the patches (this is only meaningful in case
> of the svg backend) in a very similar way that Andrew described. The
> purpose of setting ID is to do some postprocessing of the resulting
> svg file. A small post about this can be found at
>
> http://abitofpythonabitofastronomy.blogspot.com/2008/10/svg.html
>   
This is a very cool example -- and presents another great feature to add 
in the future (filtering).  Again, it's conceivable that future versions 
of PDF may have similar functionality, so we should think about generic 
ways to do it.  But that's probably another discussion...
> And my approach was also to use GCs. Although I don't quite like this
> approach, it seems to be the easiest way because, as far as I know,
> the backends in mpl does not know about the artists.
>   
You're right, the high-level artists that are exposed to the end user of 
matplotlib are somewhat removed from the low-level graphics primitives 
that are passed to the backends, and that may be problematic.  But 
adding this to the GC of an artist is the cleanest way I can think of to 
add these extra properties that need to be passed to the backends, as we 
wouldn't have to change the backend API.

Since the creation of the gc for each drawing call happens mainly in 
base classes (Patch, Text, Collection), there shouldn't be too many 
places to update to add these extra attributes to the gc.  We could 
handle these new attributes in Artist.draw and have Patch.draw, 
Text.draw, Collection.draw etc. delegate to that to reduce code duplication.
> I think we may introduce a new dictionary property to the GC class and
> also in the Artist. And modifies draw() methods of Patch and others so
> that it use these properties to pass any optioanl information (
> "url"or "id") to the backends.
>   
Are you suggesting an extra dictionary in the gc to which arbitrary 
key/value pairs can be added?  I don't like that very much.  I think if 
we're going to support hyperlinks, we should create a true API for them 
that could be used across all backends (even if most backends can't 
support the functionality).
> But I'm not sure is if it is a good idea to expose this option (or
> "url" in the Andrew's original post)  to the functions in the axes.py.
> We can just grab the return value of the "bar" command (which is a
> list of patches) and set some backend specific options for each
> patches.
>   
For the same reasons above, I don't see this as backend-specific, so I 
don't have a problem adding it as an Artist setter/kwarg that would be 
available on any method where Artist kwargs are supported.  (And 
probably analogously have a list of urls for Collections).

In the specific case of bar(), one may still be forced to manually set 
urls on each Rectangle if one wants those urls to be different.  But 
this is no different than the current situation wrt facecolor or any 
other attribute, since bar is not written on top of Collection.

Anyway, I like where this is going.  I think this will be a great addition.

Cheers,
Mike
>
> On Wed, Oct 29, 2008 at 6:06 PM, Andrew Stock
> <[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
>   

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