From prasadaraon50 at gmail.com Sat Jan 2 12:41:30 2010 From: prasadaraon50 at gmail.com (prasad rao) Date: Sat, 2 Jan 2010 03:41:30 -0800 Subject: [Tkinter-discuss] animation Message-ID: <9e3fac841001020341l130f0197y71ec2b3099960f3d@mail.gmail.com> Hi! Last month I got code to animate using sequence of images from this list. I am trying to move bubbles across a canvas. I am unable to do multiple bubbles. =code= def pp2(): def cc(): a=[x for x in range(0,500,10)] b=[x for x in range(500,0,-10)] c=[x for x in range(0,500,10)] random.shuffle(c) d=lambda : random.choice([a,b,c,a,b]) return d() z=lambda : random.randint(1,500) k=z() q=cc() def anim(cv): def view(): x1=q[cv] x2=x1+10 y1=k y2=y1+10 win.create_oval(x1,y1,x2,y2,tag='ani') win.delete('ani') try: view() except IndexError: cv=0 view() win.update_idletasks() cv=cv+1 root.after(50,anim,cv) root=Tk();win=Canvas(root,width=600,height=400);win.pack() root.after(10,anim, 0);root.mainloop() =code= please someone tell me how to make multiple bubbles move randomly across canvas on different x axis and y axises(not flashing). I sped lots of time in vain. Wish you happy New year. prasad From mark_eastwood at ntlworld.com Tue Jan 5 23:49:33 2010 From: mark_eastwood at ntlworld.com (thicket) Date: Tue, 5 Jan 2010 14:49:33 -0800 (PST) Subject: [Tkinter-discuss] help please - cannot figure this out! Message-ID: <27026738.post@talk.nabble.com> Am basically using the same code - the first which uses a function getAnchors() fails to find a match, the second which I added to help debug works fine. I just cannot see why one works and the other does not.... Could someone please put me out of my misery!! Using 2.6 ######## #!/usr/bin env python import os import fnmatch import re basedir="/home/mark/www/dev/ready" srchdirs=['/', '/static', '/static/lpi101', '/static/lpi102', '/static/lpi201', '/static/lpi202', '/static/misc','/static/images','/static/css','/static/code','/static/about'] anchor=re.compile(r'id=":[a-zA-Z].*:[0-9]{3}-[0-9]{1,2}-[0-9]{1,2}') anhref=re.compile(r'href="/.*\.(html|css|js).*?"') anchors=[] hrefs=[] def readFile(file): try: fp=open(file, 'r') allLines=fp.readlines() fp.close return allLines except IOError, e: msg='Error %d: %s' % (e.args[0], e.args[1]) return str(msg) # Anchors will only exist in .html files def getAnchors(): for eachdir in srchdirs: aDir=basedir+eachdir for aFile in os.listdir(aDir): if fnmatch.fnmatch(aFile, '*.html'): contents=readFile(aFile) if type(contents) == '': print contents else: for line in contents: res=anchor.search(line) ### Fails to find a match - though does do in the code below if res != None: anchors.append(res.group()[4:]) getAnchors() ## Below works - finds a match(s) contents=readFile('/home/mark/www/dev/ready/static/lpi101/lpi101-chapt-1-3.html') for line in contents: res=anchor.search(line) if res != None: anchors.append(res.group()[4:]) -- View this message in context: http://old.nabble.com/help-please---cannot-figure-this-out%21-tp27026738p27026738.html Sent from the Python - tkinter-discuss mailing list archive at Nabble.com. From Vasilis.Vlachoudis at cern.ch Wed Jan 6 09:08:55 2010 From: Vasilis.Vlachoudis at cern.ch (Vasilis Vlachoudis) Date: Wed, 6 Jan 2010 09:08:55 +0100 Subject: [Tkinter-discuss] help please - cannot figure this out! In-Reply-To: <27026738.post@talk.nabble.com> References: <27026738.post@talk.nabble.com> Message-ID: <4B444517.2090202@cern.ch> From a quick look, I think you are doing only one level scan. You should use the os.walk function if you want to scan the whole subdirectory structure Vasilis On 05/01/10 23:49, thicket wrote: > Am basically using the same code - the first which uses a function > getAnchors() fails to find a match, the second which I added to help debug > works fine. I just cannot see why one works and the other does not.... > > Could someone please put me out of my misery!! > Using 2.6 > > ######## > #!/usr/bin env python > import os > import fnmatch > import re > > basedir="/home/mark/www/dev/ready" > srchdirs=['/', '/static', '/static/lpi101', '/static/lpi102', > '/static/lpi201', '/static/lpi202', > '/static/misc','/static/images','/static/css','/static/code','/static/about'] > anchor=re.compile(r'id=":[a-zA-Z].*:[0-9]{3}-[0-9]{1,2}-[0-9]{1,2}') > anhref=re.compile(r'href="/.*\.(html|css|js).*?"') > > anchors=[] > hrefs=[] > > def readFile(file): > try: > fp=open(file, 'r') > allLines=fp.readlines() > fp.close > return allLines > except IOError, e: > msg='Error %d: %s' % (e.args[0], e.args[1]) > return str(msg) > > # Anchors will only exist in .html files > def getAnchors(): > for eachdir in srchdirs: > aDir=basedir+eachdir > for aFile in os.listdir(aDir): > if fnmatch.fnmatch(aFile, '*.html'): > contents=readFile(aFile) > if type(contents) == '': print contents > else: > for line in contents: > res=anchor.search(line) > ### Fails to find a match - though does do in the code below > if res != None: > > anchors.append(res.group()[4:]) > > > getAnchors() > ## Below works - finds a match(s) > contents=readFile('/home/mark/www/dev/ready/static/lpi101/lpi101-chapt-1-3.html') > for line in contents: > res=anchor.search(line) > if res != None: > anchors.append(res.group()[4:]) > > From geoff.bache at gmail.com Sat Jan 9 23:06:17 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Sat, 9 Jan 2010 23:06:17 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped Message-ID: <6e9920951001091406s2c2208a2kbea130fe588cbd2c@mail.gmail.com> 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 From klappnase at web.de Sun Jan 10 12:58:51 2010 From: klappnase at web.de (Michael Lange) Date: Sun, 10 Jan 2010 12:58:51 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001091406s2c2208a2kbea130fe588cbd2c@mail.gmail.com> References: <6e9920951001091406s2c2208a2kbea130fe588cbd2c@mail.gmail.com> Message-ID: <20100110125851.1650d20a.klappnase@web.de> Hi Geoff, On Sat, 9 Jan 2010 23:06:17 +0100 Geoff Bache 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 events. HTH Michael From geoff.bache at gmail.com Mon Jan 11 20:19:19 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Mon, 11 Jan 2010 20:19:19 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001111116s40795704w3dee9d2eaa19a107@mail.gmail.com> References: <6e9920951001111116s40795704w3dee9d2eaa19a107@mail.gmail.com> Message-ID: <6e9920951001111119u259735c3j47ae8b1afa2857a@mail.gmail.com> On Mon, Jan 11, 2010 at 8:16 PM, Geoff Bache wrote: > Hi Geoff, > > On Sat, 9 Jan 2010 23:06:17 +0100 > Geoff Bache 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 > 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 From klappnase at web.de Tue Jan 12 22:14:52 2010 From: klappnase at web.de (Michael Lange) Date: Tue, 12 Jan 2010 22:14:52 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001111119u259735c3j47ae8b1afa2857a@mail.gmail.com> References: <6e9920951001111116s40795704w3dee9d2eaa19a107@mail.gmail.com> <6e9920951001111119u259735c3j47ae8b1afa2857a@mail.gmail.com> Message-ID: <20100112221452.ba0c9abf.klappnase@web.de> Hi Geoff, (...) > > 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. 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 From peter.milliken at gmail.com Tue Jan 12 23:19:38 2010 From: peter.milliken at gmail.com (Peter Milliken) Date: Wed, 13 Jan 2010 09:19:38 +1100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <20100112221452.ba0c9abf.klappnase@web.de> References: <6e9920951001111116s40795704w3dee9d2eaa19a107@mail.gmail.com> <6e9920951001111119u259735c3j47ae8b1afa2857a@mail.gmail.com> <20100112221452.ba0c9abf.klappnase@web.de> Message-ID: <791153ba1001121419p7e4adeb7see672f58c6d328cb@mail.gmail.com> Actually it is nolonger a "bad" idea to access tk objects from two or more threads, download the package mtTkinter - someone (I forget who) very kindly provided this package that allows more than one thread to access GUI objects - since loading it I abolished all threading problems in my GUI applications (I used the threading and multiprocessing packages quite frequently in my GUI applications) - it used to be a chore to ensure that only one thread could access the GUI elements but this package removes that restriction - all for the price of a single "import" statement! Peter On Wed, Jan 13, 2010 at 8:14 AM, Michael Lange wrote: > Hi Geoff, > > (...) > > > > 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. > > 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 > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff.bache at gmail.com Wed Jan 13 20:38:53 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Wed, 13 Jan 2010 20:38:53 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001131130v694987came996b58a6bc818ec@mail.gmail.com> References: <6e9920951001131130v694987came996b58a6bc818ec@mail.gmail.com> Message-ID: <6e9920951001131138l32382520vfb3ce4c74154c2ee@mail.gmail.com> > 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 From klappnase at web.de Wed Jan 13 22:06:48 2010 From: klappnase at web.de (Michael Lange) Date: Wed, 13 Jan 2010 22:06:48 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001131138l32382520vfb3ce4c74154c2ee@mail.gmail.com> References: <6e9920951001131130v694987came996b58a6bc818ec@mail.gmail.com> <6e9920951001131138l32382520vfb3ce4c74154c2ee@mail.gmail.com> Message-ID: <20100113220648.cc990d2a.klappnase@web.de> Hi Geoff, On Wed, 13 Jan 2010 20:38:53 +0100 Geoff Bache 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('') root.deiconify() root.update() print root.winfo_ismapped() b.event_generate('') 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(). Regards Michael From geoff.bache at gmail.com Wed Jan 13 22:41:55 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Wed, 13 Jan 2010 22:41:55 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001131335y12554650r2037a95f6198821c@mail.gmail.com> References: <6e9920951001131335y12554650r2037a95f6198821c@mail.gmail.com> Message-ID: <6e9920951001131341k56c88051jf2683fcdb5743a5a@mail.gmail.com> On Wed, Jan 13, 2010 at 10:35 PM, Geoff Bache wrote: > Hi Geoff, > > On Wed, 13 Jan 2010 20:38:53 +0100 > Geoff Bache 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('') > > ? ?root.deiconify() > ? ?root.update() > > ? ?print root.winfo_ismapped() > ? ?b.event_generate('') > > ? ?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 From klappnase at web.de Wed Jan 13 23:48:08 2010 From: klappnase at web.de (Michael Lange) Date: Wed, 13 Jan 2010 23:48:08 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001131341k56c88051jf2683fcdb5743a5a@mail.gmail.com> References: <6e9920951001131335y12554650r2037a95f6198821c@mail.gmail.com> <6e9920951001131341k56c88051jf2683fcdb5743a5a@mail.gmail.com> Message-ID: <20100113234808.14820281.klappnase@web.de> Hi Geoff, On Wed, 13 Jan 2010 22:41:55 +0100 Geoff Bache wrote: (...) > > 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. > 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() 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?). Regards Michael > 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 > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss From geoff.bache at gmail.com Fri Jan 15 21:13:22 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Fri, 15 Jan 2010 21:13:22 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001151201u6d6acb13v9c56c1f8463b1217@mail.gmail.com> References: <6e9920951001151201u6d6acb13v9c56c1f8463b1217@mail.gmail.com> Message-ID: <6e9920951001151213n70913c4fk562230a3a245182a@mail.gmail.com> 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 "" events, which might be worth a go. Thanks for the suggestions anyway. Regards, Geoff From klappnase at web.de Sat Jan 16 14:14:39 2010 From: klappnase at web.de (Michael Lange) Date: Sat, 16 Jan 2010 14:14:39 +0100 Subject: [Tkinter-discuss] Persuading after_idle callback to only get called when the window is mapped In-Reply-To: <6e9920951001151213n70913c4fk562230a3a245182a@mail.gmail.com> References: <6e9920951001151201u6d6acb13v9c56c1f8463b1217@mail.gmail.com> <6e9920951001151213n70913c4fk562230a3a245182a@mail.gmail.com> Message-ID: <20100116141439.e783cf47.klappnase@web.de> Hi Geoff, On Fri, 15 Jan 2010 21:13:22 +0100 Geoff Bache wrote: > 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. So you override Tkinter.Tk() ? If yes, it should be possible to override mainloop() as well. In fact all widgets share the same mainloop() method defined in Tkinter.Misc, which is very easy to override: import Tkinter class Tk(Tkinter.Tk): def __init__(self, *args, **kw): Tkinter.Tk.__init__(self, *args, **kw) def mainloop(w, n=0): # your code here... print 'Running mainloop through widget', w._w self.tk.mainloop(n) Tkinter.Misc.mainloop = mainloop root = Tk() b = Tkinter.Button(root, text='quit', command=root.quit) b.pack(padx=100, pady=100) b.focus_set() b.mainloop() Regards Michael From shawn.meier at gmail.com Tue Jan 19 00:57:06 2010 From: shawn.meier at gmail.com (skizm) Date: Mon, 18 Jan 2010 15:57:06 -0800 (PST) Subject: [Tkinter-discuss] tkSnack record for specific period of time Message-ID: <27218833.post@talk.nabble.com> 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-tp27218833p27218833.html Sent from the Python - tkinter-discuss mailing list archive at Nabble.com. From michael.odonnell at uam.es Tue Jan 19 13:12:44 2010 From: michael.odonnell at uam.es (Michael O'Donnell) Date: Tue, 19 Jan 2010 13:12:44 +0100 Subject: [Tkinter-discuss] tkSnack record for specific period of time In-Reply-To: <27218833.post@talk.nabble.com> References: <27218833.post@talk.nabble.com> Message-ID: <47e491111001190412m3ba06bb0hd77abe2f505640cc@mail.gmail.com> Hi Shawn, Maybe try doing the recording in a separate thread: http://www.python.org/doc/current/library/thread.html Mick On Tue, Jan 19, 2010 at 12:57 AM, skizm wrote: > > 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-tp27218833p27218833.html > Sent from the Python - tkinter-discuss mailing list archive at Nabble.com. > > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > From klappnase at web.de Tue Jan 19 21:03:56 2010 From: klappnase at web.de (Michael Lange) Date: Tue, 19 Jan 2010 21:03:56 +0100 Subject: [Tkinter-discuss] tkSnack record for specific period of time In-Reply-To: <27218833.post@talk.nabble.com> References: <27218833.post@talk.nabble.com> Message-ID: <20100119210356.9a63022e.klappnase@web.de> Hi, On Mon, 18 Jan 2010 15:57:06 -0800 (PST) skizm wrote: > > 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. with this slightly modified example I get the expected 5 second sound file; doesn't this work for you ? from Tkinter import * import tkSnack root = Tk() tkSnack.initializeSnack(root) c = tkSnack.Sound(file='test.wav') c.record() root.after(5000, c.stop) root.mainloop() Michael From shawn.meier at gmail.com Tue Jan 19 21:08:59 2010 From: shawn.meier at gmail.com (skizm) Date: Tue, 19 Jan 2010 12:08:59 -0800 (PST) Subject: [Tkinter-discuss] tkSnack record for specific period of time In-Reply-To: <20100119210356.9a63022e.klappnase@web.de> References: <27218833.post@talk.nabble.com> <20100119210356.9a63022e.klappnase@web.de> Message-ID: <27231852.post@talk.nabble.com> Cool this works, I was working on the threading idea but this is much simpler. Earlier i had tried the after function but I had it tied to the frame object instead of the root object which made it not work for some reason. Thanks a lot for the help! Michael Lange wrote: > > Hi, > > On Mon, 18 Jan 2010 15:57:06 -0800 (PST) > skizm wrote: > >> >> 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. > > with this slightly modified example I get the expected 5 second sound > file; doesn't this work for you ? > > from Tkinter import * > import tkSnack > > root = Tk() > tkSnack.initializeSnack(root) > c = tkSnack.Sound(file='test.wav') > c.record() > root.after(5000, c.stop) > root.mainloop() > > Michael > > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > > -- View this message in context: http://old.nabble.com/tkSnack-record-for-specific-period-of-time-tp27218833p27231852.html Sent from the Python - tkinter-discuss mailing list archive at Nabble.com. From sunburned.surveyor at gmail.com Mon Jan 25 02:53:05 2010 From: sunburned.surveyor at gmail.com (Sunburned Surveyor) Date: Sun, 24 Jan 2010 17:53:05 -0800 Subject: [Tkinter-discuss] Setting the items of a listbox with new technique in TK 8.3 Message-ID: <71097ae21001241753g41533cc6te0e664183979eb24@mail.gmail.com> 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 From sunburned.surveyor at gmail.com Mon Jan 25 03:14:16 2010 From: sunburned.surveyor at gmail.com (Sunburned Surveyor) Date: Sun, 24 Jan 2010 18:14:16 -0800 Subject: [Tkinter-discuss] Setting the items of a listbox with new technique in TK 8.3 In-Reply-To: <20100125021308.GA10542@unpythonic.net> References: <71097ae21001241753g41533cc6te0e664183979eb24@mail.gmail.com> <20100125021308.GA10542@unpythonic.net> Message-ID: <71097ae21001241814r6a877be3na262583fe147cfce@mail.gmail.com> Jeff, I'm sure that was the problem. Thanks for the quick response and for your help. The Sunburned Surveyor On Sun, Jan 24, 2010 at 6:13 PM, Jeff Epler wrote: > The listvariable, textvariable and so forth have to be Tkinter > variables, not Python variables. > > The following program worked for me in >>>> Tkinter._tkinter.TK_VERSION; sys.version > '8.5' > '2.6.4 (r264:75706, Dec ?7 2009, 18:43:55) \n[GCC 4.4.1]' > > #!/usr/bin/python > #---- > from Tkinter import * > > app = Tk() > lv = Variable(app) > lv.set(("Roads", "Field Observations", "Railroads", "Work Areas")) > l = Listbox(app, listvariable=lv, height=3) > l.pack() > app.mainloop() > #---- > > Jeff > From jepler at unpythonic.net Mon Jan 25 03:13:08 2010 From: jepler at unpythonic.net (Jeff Epler) Date: Sun, 24 Jan 2010 20:13:08 -0600 Subject: [Tkinter-discuss] Setting the items of a listbox with new technique in TK 8.3 In-Reply-To: <71097ae21001241753g41533cc6te0e664183979eb24@mail.gmail.com> References: <71097ae21001241753g41533cc6te0e664183979eb24@mail.gmail.com> Message-ID: <20100125021308.GA10542@unpythonic.net> The listvariable, textvariable and so forth have to be Tkinter variables, not Python variables. The following program worked for me in >>> Tkinter._tkinter.TK_VERSION; sys.version '8.5' '2.6.4 (r264:75706, Dec 7 2009, 18:43:55) \n[GCC 4.4.1]' #!/usr/bin/python #---- from Tkinter import * app = Tk() lv = Variable(app) lv.set(("Roads", "Field Observations", "Railroads", "Work Areas")) l = Listbox(app, listvariable=lv, height=3) l.pack() app.mainloop() #---- Jeff From geoff.bache at gmail.com Tue Jan 26 10:11:31 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Tue, 26 Jan 2010 10:11:31 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination Message-ID: <6e9920951001260111j49d24659uf7e3d0ee9d161843@mail.gmail.com> 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("", 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 From klappnase at web.de Tue Jan 26 11:34:03 2010 From: klappnase at web.de (Michael Lange) Date: Tue, 26 Jan 2010 11:34:03 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination In-Reply-To: <6e9920951001260111j49d24659uf7e3d0ee9d161843@mail.gmail.com> References: <6e9920951001260111j49d24659uf7e3d0ee9d161843@mail.gmail.com> Message-ID: <20100126113403.6bf2dcb5.klappnase@web.de> Hi Geoff, On Tue, 26 Jan 2010 10:11:31 +0100 Geoff Bache 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. Of course, if you have some code that should be called after the window is closed, you can also simply put it below the mainloop(). > > I tried binding to the "destroy" event like this: > > from Tkinter import * > > def destroyed(*args): > print "AAARRGGGH!!!" > :))) Regards Michael From geoff.bache at gmail.com Tue Jan 26 13:45:49 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Tue, 26 Jan 2010 13:45:49 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination In-Reply-To: <6e9920951001260434h1217b4a5lc7463f74d3eff5fd@mail.gmail.com> References: <6e9920951001260434h1217b4a5lc7463f74d3eff5fd@mail.gmail.com> Message-ID: <6e9920951001260445t71455940vb5e4a24bd2661335@mail.gmail.com> On Tue, Jan 26, 2010 at 1:34 PM, Geoff Bache wrote: > Hi Geoff, > > On Tue, 26 Jan 2010 10:11:31 +0100 > Geoff Bache 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 "" 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 and exclude programmatic calls via interception.) Thanks, Geoff From klappnase at web.de Tue Jan 26 19:32:20 2010 From: klappnase at web.de (Michael Lange) Date: Tue, 26 Jan 2010 19:32:20 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination In-Reply-To: <6e9920951001260445t71455940vb5e4a24bd2661335@mail.gmail.com> References: <6e9920951001260434h1217b4a5lc7463f74d3eff5fd@mail.gmail.com> <6e9920951001260445t71455940vb5e4a24bd2661335@mail.gmail.com> Message-ID: <20100126193220.9ad4f3a9.klappnase@web.de> Hi Geoff, On Tue, 26 Jan 2010 13:45:49 +0100 Geoff Bache wrote: (...) > 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 "" like I did? That seemed > the intuitive way to go, and it seems to work on Linux... > I don't have a windows box at hand, so I cannot tell. On my linux box it works, but when I bind the callback to the root tk window the callback is triggered once for every child widget of root. > (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 and > exclude programmatic > calls via interception.) > Just a thought... IIRC last time I suggested to override mainloop(); if this is an option you could put your "destroy" callback into the custom mainloop() function, below self.tk.mainloop(n). Regards Michael From geoff.bache at gmail.com Tue Jan 26 20:00:56 2010 From: geoff.bache at gmail.com (Geoff Bache) Date: Tue, 26 Jan 2010 20:00:56 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination In-Reply-To: <20100126193220.9ad4f3a9.klappnase@web.de> References: <6e9920951001260434h1217b4a5lc7463f74d3eff5fd@mail.gmail.com> <6e9920951001260445t71455940vb5e4a24bd2661335@mail.gmail.com> <20100126193220.9ad4f3a9.klappnase@web.de> Message-ID: <6e9920951001261100y72f80dd7r3c857e707651a512@mail.gmail.com> Hi again Michael, >> Why doesn't it work to bind to "" like I did? That seemed >> the intuitive way to go, and it seems to work on Linux... >> > > I don't have a windows box at hand, so I cannot tell. On my linux box > it works, but when I bind the callback to the root tk window the > callback is triggered once for every child widget of root. Yes, that's true. It's easy to fix that though of course. Maybe I should report this as a Python bug? It presumably shouldn't be possible to crash Python like this just by writing Python code. > >> (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 and >> exclude programmatic >> calls via interception.) >> > > Just a thought... IIRC last time I suggested to override mainloop(); if > this is an option you could put your "destroy" callback into the custom > mainloop() function, below self.tk.mainloop(n). Yes, maybe something like that could work. It feels a bit convoluted but I guess there aren't too many other options available that I can see. Thanks, Geoff From klappnase at web.de Tue Jan 26 20:26:34 2010 From: klappnase at web.de (Michael Lange) Date: Tue, 26 Jan 2010 20:26:34 +0100 Subject: [Tkinter-discuss] Doing things on Tkinter termination In-Reply-To: <6e9920951001261100y72f80dd7r3c857e707651a512@mail.gmail.com> References: <6e9920951001260434h1217b4a5lc7463f74d3eff5fd@mail.gmail.com> <6e9920951001260445t71455940vb5e4a24bd2661335@mail.gmail.com> <20100126193220.9ad4f3a9.klappnase@web.de> <6e9920951001261100y72f80dd7r3c857e707651a512@mail.gmail.com> Message-ID: <20100126202634.86b39dd8.klappnase@web.de> Hi, On Tue, 26 Jan 2010 20:00:56 +0100 Geoff Bache wrote: > Hi again Michael, > > >> Why doesn't it work to bind to "" like I did? That seemed > >> the intuitive way to go, and it seems to work on Linux... > >> > > > > I don't have a windows box at hand, so I cannot tell. On my linux > > box it works, but when I bind the callback to the root tk window the > > callback is triggered once for every child widget of root. > > Yes, that's true. It's easy to fix that though of course. > > Maybe I should report this as a Python bug? It presumably shouldn't be > possible to crash Python like this just by writing Python code. I guess this is rather the way Tk handles the Destroy event than a python bug. At least the way the Destroy event from child widgets is propagated to the parent is the same in pure Tk. And from the "bind" man page: Destroy A Destroy event is delivered to a window when it is destroyed. When the Destroy event is delivered to a widget, it is in a ``half-dead'' state: the widget still exists, but most operations on it will fail. Though I don't know details, this seems to say that callbacks may be delicate and should be used with care. Regards Michael > > > > >> (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 and > >> exclude programmatic > >> calls via interception.) > >> > > > > Just a thought... IIRC last time I suggested to override mainloop > > (); if this is an option you could put your "destroy" callback into > > the custom mainloop() function, below self.tk.mainloop(n). > > Yes, maybe something like that could work. It feels a bit convoluted > but I guess there aren't too many other options available that I can > see. > > Thanks, > Geoff From kalman_g at msn.com Wed Jan 27 23:27:56 2010 From: kalman_g at msn.com (GKalman) Date: Wed, 27 Jan 2010 14:27:56 -0800 (PST) Subject: [Tkinter-discuss] Swapping 2 widgets btween 2 cells in a grid-layout Message-ID: <27347924.post@talk.nabble.com> 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-tp27347924p27347924.html Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.