I went here:
http://matplotlib.sourceforge.net/api/index_backend_api.html
and didn't see tkagg listed.
Trevor
Trevor,
Thank you. It is still missing from the devel branch, along with several others. I can see how this could cause some confusion. Maybe we can get it fixed before the next release, maybe not.
Part of the problem here is that auto-generation of docs saves a huge amount of work, but can also lead to problems, of which this is just one example.
Eric
···
On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
----- Original Message -----
From: "Eric Firing"<efiring@...229...>
To: matplotlib-users@lists.sourceforge.net
Sent: Wednesday, August 31, 2011 10:33:45 AM
Subject: Re: [Matplotlib-users] Matplotlib 1.0.1 Tk backend
On 08/31/2011 04:01 AM, Trevor J Christensen wrote:
In preparing to upgrade from 0.99 to 1.0.1, I was reading the online
documentation about the various backends. I do not see a TkAgg backend
listed. Is that because there is no longer a backend for Tk? Has support
for Tk been dropped in 1.0.1? Or has it not yet been added to the
documentation?
Trevor
Trevor,
Where did you expect to find it, but not see it?
Eric
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
It wouldn’t be that difficult to add references to those other backends, however I do not know how complete their documentations are. As an interesting note, the GTKAgg API docs are currently commented out with a note saying that an active X-window session is needed to import the GTK backends. Was this preventing the GTK docs from building? How come do other GUI backends still build fine?
Ben Root
···
On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <efiring@…229…> wrote:
On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
I went here:
http://matplotlib.sourceforge.net/api/index_backend_api.html
and didn’t see tkagg listed.
Trevor
Trevor,
Thank you. It is still missing from the devel branch, along with
several others. I can see how this could cause some confusion. Maybe
we can get it fixed before the next release, maybe not.
Part of the problem here is that auto-generation of docs saves a huge
amount of work, but can also lead to problems, of which this is just one
example.
Eric
> I went here:
>
> http://matplotlib.sourceforge.net/api/index_backend_api.html
>
> and didn't see tkagg listed.
>
> Trevor
Trevor,
Thank you. It is still missing from the devel branch, along with
several others. I can see how this could cause some confusion. Maybe
we can get it fixed before the next release, maybe not.
Part of the problem here is that auto-generation of docs saves a huge
amount of work, but can also lead to problems, of which this is just one
example.
Eric
It wouldn't be that difficult to add references to those other backends,
however I do not know how complete their documentations are. As an
interesting note, the GTKAgg API docs are currently commented out with a
note saying that an active X-window session is needed to import the GTK
backends. Was this preventing the GTK docs from building? How come do
other GUI backends still build fine?
That seems to be just a peculiarity of the particular gui toolkits. It is possible to import the others without a display; they don't fail until one tries to plot something.
Eric
···
On 09/02/2011 04:48 AM, Benjamin Root wrote:
On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> wrote:
On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
Ben Root
> I went here:
>
> http://matplotlib.sourceforge.net/api/index_backend_api.html
>
> and didn't see tkagg listed.
>
> Trevor
Trevor,
Thank you. It is still missing from the devel branch, along with
several others. I can see how this could cause some confusion. Maybe
we can get it fixed before the next release, maybe not.
Part of the problem here is that auto-generation of docs saves a huge
amount of work, but can also lead to problems, of which this is just one
example.
Eric
It wouldn't be that difficult to add references to those other backends,
however I do not know how complete their documentations are. As an
interesting note, the GTKAgg API docs are currently commented out with a
note saying that an active X-window session is needed to import the GTK
backends. Was this preventing the GTK docs from building? How come do
other GUI backends still build fine?
Now I see it: all the other backends are simply setting constants in their cursord, so they are not calling the functions that create the cursors until runtime; backend_gtk is calling the functions at import time. This is a design deficiency that will be easy to fix, and will help prevent quite a few problems (including problems I have run into myself).
I will take care of it today or tomorrow.
Eric
···
On 09/02/2011 04:48 AM, Benjamin Root wrote:
On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> wrote:
On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
Ben Root
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I was too optimistic. Moving the cursor creation to runtime is easy, but it triggers an avalanche of warnings and errors, sometimes ending in a segfault, if one tries to plot anything when there is no X display. Better to leave it the way it is, failing at import.
Eric
···
On 09/02/2011 08:54 AM, Eric Firing wrote:
Now I see it: all the other backends are simply setting constants in
their cursord, so they are not calling the functions that create the
cursors until runtime; backend_gtk is calling the functions at import
time. This is a design deficiency that will be easy to fix, and will
help prevent quite a few problems (including problems I have run into
myself).
I will take care of it today or tomorrow.
Eric
That’s too bad. Actually, a better, more generic solution would be if there was some way for sphinx to create documentation without actually performing an import. This would be valuable for backends like cocoaagg and macosx backends as those two require PyObjC which (AFAICT) can’t be installed on a non-mac system.
Anyway, I had some free time and did some grunt-work. Please see my branch here:
https://github.com/WeatherGod/matplotlib/compare/docfix%2Fbackends
The entires in the TOCs probably need some smarter reorganizatiion (fltkagg got added to the wrong place…), and I didn’t try building these docs in a headless environment, so I don’t know which ones would fail in that situation.
Cheers!
Ben Root
···
On Fri, Sep 2, 2011 at 2:16 PM, Eric Firing <efiring@…229…> wrote:
On 09/02/2011 08:54 AM, Eric Firing wrote:
Now I see it: all the other backends are simply setting constants in
their cursord, so they are not calling the functions that create the
cursors until runtime; backend_gtk is calling the functions at import
time. This is a design deficiency that will be easy to fix, and will
help prevent quite a few problems (including problems I have run into
myself).
I will take care of it today or tomorrow.
Eric
I was too optimistic. Moving the cursor creation to runtime is easy,
but it triggers an avalanche of warnings and errors, sometimes ending in
a segfault, if one tries to plot anything when there is no X display.
Better to leave it the way it is, failing at import.
Eric