2010/9/21 Brian Blais <bblais@...1129...>:
actually, I think the workflow that I use doesn't lend itself well to this. usually what I do is write code in the local space, in a if __name__=="__main__" block, so that after things run I can easily inspect variables, test the results, rerun, etc... It's only after things work that I box it into a nice function that can be called with an event callback. this is one of the reasons I use python, so that I can easily interact with my data.
why does the way I wrote things play havoc with GUI event loops? it shouldn't care, or at worst the GUI parts of the window (menus, buttons) should be unresponsive when the plots are drawn but the plots should at least be drawn!
You must be with Tkinter extremely careful when having no mainloop()
call. There is no separate thread keeping the GUI mainloop poll
running when you import Tkinter (or matplotlib does). I.e., you have
two options, at least:
1) You implement your own mainloop, like calling the main widget's
.update() method repeatedly
2) You use Tkinter .after(), what I guess the Timer object will do.
What you should definitely avoid, just in case, is calling Tkinter
methods from *another* thread than those which imported Tkinter (this
is those which imported matplotlib in your case). Not adhering to
this rule will lead to unpredictable behaviour, especially on OS X (I
went through it, and it's painful). You don't do this atm, just don't
do it in future too.
The normal-users usecase of TkAgg is an interactive Python session.
For some reason I don't understand myself, it works there. Obviously
the Tkinter update poll is done when you enter the prompt or something
like that. In a script, you have no prompt, so you have no update, I
could imagine, but though, draw() should do that.
The benefit is that the timed updates integrate into the
GUI event loop and don't fight it. The other benefit is that this
works with any of the interactive backends and you don't end up
debugging weird draw problems. Even when I've gotten your style of
animation to work in the past, I've still had problems where resizing
the figure, etc. don't work.
perhaps I can write things this way, and have the function inject into locals(), just to make it easier to debug the results, but that seems to me to be a bit of a hack. I'm not really interested in an animation, as much as easily visualizing my data every so often.
I don't like that local() approach too, it really sounds hackish. You
can use a bound class method (i.e., a method of some instance of some
class coded by you), and this will have access to self.*. Do you like
this? The method would be the timer target.
when people come from using matlab, and then hit odd draw problems like this, it is disconcerting.
Maybe; maybe Python is just not the same as Matlab? To argument, the
graphical backend is not embedded into Python, Tkinter is a package,
although it ships with Python.