Agg backend problem with 0.53

I shouldn't have jumped to conclusions. Agg seems OK. GTKAgg works from SciTE and IDLE just using show().
If I substitute this:

manager = get_current_fig_manager()

then a window is opened but nothing is painted onto the canvas area from either IDLE or SciTE.
It looks like GTKAgg might be the backend of choice for these environments.



----- Original Message -----
From: John Hunter <jdhunter@...4...>
Date: Thu, 22 Apr 2004 08:09:52 -0500
To: "Gary Ruben" <gazzar@...25...>
Subject: Re: [Matplotlib-users] Agg backend problem with 0.53

    > It's evidently something to do with threads and is probably
    > an inherent problem with Agg. I'm just bringing this to the
    > attention of others here who may be having similar
    > problems. Perhaps John knows what's going on and whether
    > anything can be done about it. The convenience of working in
    > SciTE For the moment,

I would be very surprised if it's agg - I think it's a GUI conflict on
the Tk side. Todd is this related to the idle -n thingie? If so,
perhaps a FAQ and status report are warranted.

Gary, since you say GTK is working, you may also want to check GTKAgg
which will help up narrow it down to Tk, and would rule out agg
problems. But since SciTE is GTK based, you probably need make sure
that matplotlib is not firing up it's own gtk mainloop, by not calling
'show'. You can show your GTK figures manually if necessary by doing

   manager = get_current_fig_manager()

This is a GTK specific call applicable only if the GTK mainloop is
already running (as I suspect it is in SciTE, which I haven't used),
It is probably a good idea to standardize the API here across GUIs to
handle exactly this case.

The larger question is why would there be a GTK/Tk conflict? In any
case, let us know if you learn anything else.


Sign-up for Ads Free at

Thanks for all the great features in matplotlib 0.53. with 0.53 looks normal initially. However, if you compress
the scale by clicking the (-) Horizontal magnifier, the new date
ticklabels that shift in from the right are horizontal, not vertical.

I found that if you expand and then compress, the original ticklabels
remain vertical, but the new ones (those not present in the original
plot) shift in horizontal. Looks like the 'rotation' attribute of the
additional ticklabels should have been copied from the original ones.

  -Al Schapira

I had been using multi-line ticklabels in my plots. They worked fine in
in 0.52 (except for postscript output). Much to my dismay, I find that
in 0.53 multi-line ticklabels do not work at all. The embedded '\n'
shows up as a small box, and the lines run together.

I hope that this will be fixed soon.


  -Al Schapira