Hi John, I probably didn't make it clear, but TkAgg has
> problems too. Here's what I know: Under 0.53.1 TkAgg and
> GTKAgg both worked fine, both when running the script
> directly from Windows Explorer in which case file
> association cause python to fire up in a DOS shell, and when
> running it from within SciTE or IDLE things are fine
> too. 0.54 has changed something.
Well, it's changed a lot. The big dollar question is which of these
changes are causing these problems
> I tried grabbing and
> running a few examples from CVS as well as my own previously
> working examples. They behave consistently - GTKAgg no
> longer works at all
I need clarification here. What does it mean "no longer works at
all". If you open up a DOS command shell and run
from matplotlib.matlab import *
c:> python myscript.py -dGTKAgg
what happens? When you run from windows explorer and get a traceback,
you often lose the DOS window that provides the required information.
So it's best to debug from a command shell, though admittedly most of
the windows shells suck.
> and TkAgg works but only if I run it from DOS with a
> -dTkAgg option. It may be a GUI conflict but it has only
> started to conflict with 0.54. removing show() or replacing
> it with show(mainloop=False) seem to make no difference to
> the behaviour running TkAgg from SciTE.
show(mainloop=False) would only be expected to have any effect with
GTK*, but I understand that it's not helping in that case either.
> I do notice that
> the python >>> prompt comes up in any DOS windows when
> running with the -dTkAgg option after the Tk plot window
> displays. Closing the window then leaves the python prompt
> and I have to ^Z it to shut it down. It's like it thinks it
> should be running in interactive mode, although 'interactive
> : False' is set in my .matplotlibrc This seems abnormal to
This is intentional. Since Tkinter doesn't have a mainloop, we switch
python to interactive mode after TkAgg finishes it's business and the
Tk window remains open until the python shell is closed.
> In my original post I asked if anyone else had success or
> problems in Win98 and since noone replied, maybe we can
> assume that I'm one of the rare users who's still using
> it. Therefore, as much as I (and probably you) would like to
> get to the bottom of what's happening, it's probably Win98
> specific and therefore, can probably wait; at least until
> after my upcoming exams are over and I get a chance to
I would be surprised if it's win98 specific. I haven't seen any
problems so far that were specific to just one windows OS. They're
basically all the same as far as I can see, Microsoft just keeps
shrinkwrapping them and recharging you for them I have win98 at
home so I'll try and test a version there.
> really look into it some more. So I might go quiet for a few
> weeks unless you want me to try anything quick and specific.
> Finally, I hope you didn't lose the ecolor changes I made to
> errorbars and they might make it into a future version
No, I missed them the first time but when cleaning out my inbox found
them and made an entry on the TODO list, so they'll get merged soon
If you could try the command shell test with GTKAgg that I asked for
above, that would be great.