2010/9/21 Brian Blais <bbl...@bryant.edu>: > 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. Friedrich >> 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. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
