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 yo
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
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
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 de
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
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], [
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
stan
Another use case in favor of implementation of the URL property at the
artist level:
Consider a map with scatter points representing geolocated photos that
can be viewed at some URL. Attach a mouse click on the artist to the
following code:
import webbrowser
webbrowser.open(patch.url)
And you have
On Thu, Oct 30, 2008 at 8:10 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> In the specific case of bar(), one may still be forced to manually set
> urls on each Rectangle if one wants those urls to be different. But
> this is no different than the current situation wrt facecolor or any
> ot
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
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
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.
12 matches
Mail list logo
