Mailman 3 January 2010 - Tkinter-discuss

Swapping 2 widgets btween 2 cells in a grid-layout
by GKalman Feb. 3, 2010

Feb. 3, 2010

I would like to swap the (grid cell) positions of 2 label-widgets (in an array of widgets) in response to a mouse-event. (I have no trouble swapping variables, but can't do it with widgets). Any suggestions or references would be appreciated. -- View this message in context: http://old.nabble.com/Swapping-2-widgets-btween-2-cells-in-a-grid-layout-tp… Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.

2 1

Re: [Tkinter-discuss] Doing things on Tkinter termination
by Geoff Bache Jan. 26, 2010

Jan. 26, 2010

On Tue, Jan 26, 2010 at 1:34 PM, Geoff Bache <geoff.bache(a)gmail.com> wrote: > Hi Geoff, > > On Tue, 26 Jan 2010 10:11:31 +0100 > Geoff Bache <geoff.bache at gmail.com> wrote: > >> Hi all, >> >> How would you add some code that is called when the application is >> terminated, that is independent of whether it was closed via the >> window manager or via some programmatic call within the application, >> such as a call from a "quit" button? > > root.protocol("WM_DELETE_WINDOW", your_quit_method) > > This way, your_quit_method() will be called when the window manager > closes the window through the window's "close" button (i.e. usually the > cross in the upper right corner) or through Alt-F4 or so. In most cases > it is a good idea to define a "WM_DELETE_WINDOW" callback even if it is > only root.quit() to make sure you have control over what happens when > the user clicks the "close" button. Hi Michael, Yes, I'd seen that, but it doesn't really fit the criteria of being independent of how it's closed. As far as I can see it will get called when the window's close button is pressed, and nothing else, so if the application itself calls "destroy", it won't actually get called. Why doesn't it work to bind to "<Destroy>" like I did? That seemed the intuitive way to go, and it seems to work on Linux... (To explain some more, I'm still on my GUI testing effort from my previous question and am trying to handle window closures. So another potential solution would be if there was some way to simulate the actual window closure and programmatically trigger the window to be closed in the window manager. But I couldn't see a way to do that. So the next best thing for me was to use <Destroy> and exclude programmatic calls via interception.) Thanks, Geoff

2 3

Doing things on Tkinter termination
by Geoff Bache Jan. 26, 2010

Jan. 26, 2010

Hi all, How would you add some code that is called when the application is terminated, that is independent of whether it was closed via the window manager or via some programmatic call within the application, such as a call from a "quit" button? I tried binding to the "destroy" event like this: from Tkinter import * def destroyed(*args): print "AAARRGGGH!!!" root = Tk() button = Button(root, text="QUIT", command=root.quit) button.grid() # This line seems to lead to Python crashes on Windows root.bind("<Destroy>", destroyed, "+") root.mainloop() but this produces Python crashes on Windows, and doesn't work on Linux either if the Quit button is pressed. Changing to "command=root.destroy" works on Linux but produces a hang on Windows. There must be a better way, surely? Regards, Geoff

2 1

Setting the items of a listbox with new technique in TK 8.3
by Sunburned Surveyor Jan. 25, 2010

Jan. 25, 2010

I'm new to Tkinter programming, and I'm fairly new to Python. (I come from a Java programming background.) I've been trying to put together my first Tk GUI with Tkinter. I've been reading some of the documentation at tkdocs.com. The documentation at tkdocs.com mentions using the list variable option made available in Tk 8.3 to set the items of a list box, instead of using the old insert method. I can successfully add items to the listbox in Tkinter using the old insert method, but I'm having trouble with the new method. I create a list of strings stored in a variable, and then pass the name of this variable as an option when creating the listbox as follows: featureTypesList = ("Roads", "Field Observations", "Railroads", "Work Areas") featureTypeListbox = Listbox(mainFrame, listvariable=featureTypesList, height=3) However, when I display my GUI on the screen, none of the values in my list show up in my listbox. Is there another step that I am missing? Do I need to do something else to "bind" the values in my list to the listbox? I appreciate any suggestions. I'm using Python 3.1 with the built-in Tkinter and ttk modules on Microsoft Windows XP. Here is the link for the web page at tkdocs.com that I have been reading to learn about the use of the listbox widget in Tkinter: http://www.tkdocs.com/tutorial/morewidgets.html#listbox The Sunburned Surveyor

2 2

tkSnack record for specific period of time
by skizm Jan. 19, 2010

Jan. 19, 2010

I am currently trying to write a code snippet that will record for a set period of time and I have tried a number of methods to do this yet none have worked, the first one I tried is listed below. from Tkinter import * import time root = Tk() import tkSnack tkSnack.initializeSnack(root) c = tkSnack.Sound() c.record() time.sleep(5) #record for 5 seconds c.stop() This produces an apparently empty sound file, I assume that what is going on here is that the sleep command pauses the entire program including what I am trying to record. I am sure that there is some proper way to do this but after searching for quite a while I am at a loss as to what it may be. In addition to the sleep I have tried the .after(...) member function of the master object. I have tried this with a record and stop button and it works fine. Thank you for your help. -- View this message in context: http://old.nabble.com/tkSnack-record-for-specific-period-of-time-tp27218833… Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.

3 3

Re: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped
by Geoff Bache Jan. 16, 2010

Jan. 16, 2010

Hi again Michael, > > Hmm, from your previous posts I thought you would just do the call to > root.after_idle(self.replayEvents) right before root.mainloop() ? > If so, why not do > > root.deiconify() > root.update() > root.after_idle(self.replayEvents) > root.mainloop() The problem is that I have to break in by intercepting something as the application code doesn't know I exist :) At the moment I'm intercepting the construction of Tk() which is guaranteed to happen and is easy to intercept. Intercepting mainloop is more problematic because all widgets have a mainloop method and there's no knowing which one the application will call. > > I don't think there is any risk in using update() like this. I am > afraid I did not understand you properly though, and what you are trying > is more complex than I thought. I actually don't have any experience > with gui testing tools :) > Another idea, which looks a little hackish, but maybe does the trick as > well, is to add a test if the window is visible to the replayEvents() > method and if not call it again after 100 ms or so, like: > > def replayEvents(self): > if root.winfo_ismapped(): > # do things.... > else: > root.after(100, self.replayEvents) > > Really not nice, but simple (and maybe effective?). Yes, I can maybe make it work with sleeps like this if I have to. I also haven't yet tried your solution of using "<Map>" events, which might be worth a go. Thanks for the suggestions anyway. Regards, Geoff

2 1

Re: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped
by Geoff Bache Jan. 13, 2010

Jan. 13, 2010

On Wed, Jan 13, 2010 at 10:35 PM, Geoff Bache <geoff.bache(a)gmail.com> wrote: > Hi Geoff, > > On Wed, 13 Jan 2010 20:38:53 +0100 > Geoff Bache <geoff.bache at gmail.com> wrote: > > (...) >> Hi Michael, >> >> I'm trying to write a basic GUI testing tool (in fact, I'm trying to >> add basic Tkinter support to PyUseCase, which has only worked with >> PyGTK so far) >> >> The basic plan when replaying is thus to add an idle handler that can >> generate GUI events for me. >> >> I assumed I would just do >> >> root.after_idle(self.replayEvents) >> >> as I do with PyGTK, but as discussed that failed because it tried to >> simulate events before the widgets were mapped and hence ready to >> receive the events. >> >> Instead I have now done the following: >> >> thread = Thread(target=self.addIdleHandler) >> thread.run() >> >> def addIdleHandler(self): >> root.wait_visibility() >> root.after_idle(self.replayEvents) >> >> def replayEvents(self): >> root.update_idletasks() >> # ... actually do stuff >> >> I must say I don't understand how wait_visibility would work if I >> didn't call it in a different thread. I can't call it in the main >> thread or it will cause deadlock, surely? It is that thread that is >> going to map my widgets so I can't block in it >> waiting for that to happen. >> >> As you can see, the thread is only adding the idle handler, it isn't >> actually doing anything with the widgets itself. >> > > It still looks dangerous to me, because your addidleHandler() calls the > tk methods. Maybe you could try the mtTkinter package Peter suggested > if you want to use threads (I don't know it, so I cannot tell), however > I still think there should be a simpler solution. The suggestion with > wait_visibility() was just a quick shot in the dark; maybe something > like this would do the trick for you: > > from Tkinter import * > root = Tk() > > def foo(): > print 'foo' > > b = Button(root, text='blah', command=foo) > b.pack(padx=100, pady=100) > b.focus_set() > > print root.winfo_ismapped() > b.event_generate('<space>') > > root.deiconify() > root.update() > > print root.winfo_ismapped() > b.event_generate('<space>') > > root.mainloop() > > > Here on my box the first winfo_ismapped() returns 0, the second one 1 > which seems to say that after the root.update() the window is already > visible; the first call to event_generate() seems to be lost here, too, > but after root.update() the event is triggered as expected. > If this does not work for you, another approach might be to use a > withdrawn root window and pack your widgets into a Toplevel window, > which allowed you to use wait_visibility(). > Hi Michael, Thanks for your detailed reply. I feel also that there should be a simpler solution and I can't say I *want* to use threads exactly. What I think you're missing above is that a GUI testing tool is supposed to deal with an arbitrary application under test so I don't have any control over the widgets and how they're packed. That also makes it difficult to call root.update() because I don't know when the application would be ready for me to do so. In any case, the documentation for update() is as follows: "This method forces the updating of the display. It should be used only if you know what you're doing, since it can lead to unpredictable behavior or looping. It should never be called from an event callback or a function that is called from an event callback." makes it sound just about as risky as what I'm doing at the moment... especially as I can't really claim I know what I'm doing having looked at tkinter for the first time less than a week ago :) Regards, Geoff

2 1

Re: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped
by Geoff Bache Jan. 13, 2010

Jan. 13, 2010

> This sounds like you are trying to access tk from within two different > threads which is generally a bad idea, though it may *seem* to work > sometimes. > Maybe we can provide better help if you could post a short code snippet > that demonstrates your problem. > > Regards > > Michael > Hi Michael, I'm trying to write a basic GUI testing tool (in fact, I'm trying to add basic Tkinter support to PyUseCase, which has only worked with PyGTK so far) The basic plan when replaying is thus to add an idle handler that can generate GUI events for me. I assumed I would just do root.after_idle(self.replayEvents) as I do with PyGTK, but as discussed that failed because it tried to simulate events before the widgets were mapped and hence ready to receive the events. Instead I have now done the following: thread = Thread(target=self.addIdleHandler) thread.run() def addIdleHandler(self): root.wait_visibility() root.after_idle(self.replayEvents) def replayEvents(self): root.update_idletasks() # ... actually do stuff I must say I don't understand how wait_visibility would work if I didn't call it in a different thread. I can't call it in the main thread or it will cause deadlock, surely? It is that thread that is going to map my widgets so I can't block in it waiting for that to happen. As you can see, the thread is only adding the idle handler, it isn't actually doing anything with the widgets itself. Regards, Geoff

2 1

Re: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped
by Geoff Bache Jan. 12, 2010

Jan. 12, 2010

On Mon, Jan 11, 2010 at 8:16 PM, Geoff Bache <geoff.bache(a)gmail.com> wrote: > Hi Geoff, > > On Sat, 9 Jan 2010 23:06:17 +0100 > Geoff Bache <geoff.bache at gmail.com> wrote: > >> Hi all, >> >> I'm trying to add an idle callback via the after_idle method, called >> before mainloop. The problem is that I want to interact with the GUI >> widgets >> (doing very basic GUI testing) from this callback so I need the window >> to be mapped by the window manager. But my callback gets called before >> this has happened. If I then just call after_idle again from it the >> window never appears at all. >> >> Is there a nice way of waiting until there is a window to play with >> before calling it? I can hardcode a delay by calling "after" instead, >> and >> this works but is obviously not ideal. >> > > Have you tried wait_visibility() ? > If this doesn't work for you, maybe you could bind a callback to <Map> > events. I have got something that seems to work now, which is to create a thread, call wait_visibility in it and then add the idle handler, and then call update_idletasks at the beginning of the idle handler. Feels to me like all that fuss shouldn't really be necessary, but there we are. If anyone knows of a simpler way I'd be interested to hear what it is. Thanks, Geoff

3 2

Persuading after_idle callback to only get called when the window is mapped
by Geoff Bache Jan. 10, 2010

Jan. 10, 2010

Hi all, I'm trying to add an idle callback via the after_idle method, called before mainloop. The problem is that I want to interact with the GUI widgets (doing very basic GUI testing) from this callback so I need the window to be mapped by the window manager. But my callback gets called before this has happened. If I then just call after_idle again from it the window never appears at all. Is there a nice way of waiting until there is a window to play with before calling it? I can hardcode a delay by calling "after" instead, and this works but is obviously not ideal. Regards, Geoff Bache

2 1