[pygtk] gobject.timeout_add() won't work after calling gtk.threads_init() on windows xp
Hi, everyone Following simple code will hang forever on windows XP, and the check dialog text is never outputted to console. The window created in the code showed but is blocked (when I move mouse into the window area, the mouse pointer is always a loading icon) */|import gtk import gobject def checkDialog(): print 'check dialog' return True gobject.timeout_add(500, checkDialog) gtk.threads_init() w= gtk.Window() w.show() gtk.main()|/* While same code works well on Windows 7 Runtime details: Windows XP SP3, python 2.7.5, pytgtk-2.24-allinone ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.timeout_add() won't work after calling gtk.threads_init() on windows xp
Have you tried calling gtk.threads_init() before gobject.timeout_add(...)? On Wed, Jun 26, 2013 at 5:56 AM, Todong Ma gbstac...@gmail.com wrote: Hi, everyone Following simple code will hang forever on windows XP, and the check dialog text is never outputted to console. The window created in the code showed but is blocked (when I move mouse into the window area, the mouse pointer is always a loading icon) import gtk import gobject def checkDialog(): print 'check dialog' return True gobject.timeout_add(500, checkDialog) gtk.threads_init() w = gtk.Window() w.show() gtk.main() While same code works well on Windows 7 Runtime details: Windows XP SP3, python 2.7.5, pytgtk-2.24-allinone ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.timeout_add() won't work after calling gtk.threads_init() on windows xp
On 2013/6/26 18:56, Todong Ma wrote: Hi, everyone Following simple code will hang forever on windows XP, and the check dialog text is never outputted to console. The window created in the code showed but is blocked (when I move mouse into the window area, the mouse pointer is always a loading icon) */|import gtk import gobject def checkDialog(): print 'check dialog' return True gobject.timeout_add(500, checkDialog) gtk.threads_init() w= gtk.Window() w.show() gtk.main()|/* While same code works well on Windows 7 Runtime details: Windows XP SP3, python 2.7.5, pytgtk-2.24-allinone Just now Juhaz on the IRC channel told me I should try gtk.gdk.threads_init() or gobject.threads_init() instead of gtk.threads_init(). Then I tried them and found it works by using gobject.threads_init()! Thank you all! ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.timeout_add()
Il giorno sab, 23/01/2010 alle 15.51 -0800, dj ha scritto: Thanks for your continued help on this, Pietro. Here is a very basic look at what the program does: 1. At a specified time, tune the radio and launch ecasound to make a recording. 2. After the recording has finished, tune the radio to another frequency and launch ecasound again. The version of the program I had been using launched ecasound in a thread so that the GUI would not be blocked. gobject.timeout_add() was used to stop the program from immediately re-tuning and trying to record again before the previous recording was finished. This happens hourly plus an additional 0-4 schedules within each hour. When I tried to add another schedule within the hour, I couldn't get gobject.timeout_add() to work with it. The threaded version uses os.system() to launch ecasound. I've been experimenting with subprocess.Popen and subprocess.call in the non-threaded version, but I don't understand those too well, and they both block the GUI. I understand that nobody has suggested that I block the GUI, but I can live with that as long as the rest of the program works. import sys import subprocess p = subprocess.Popen(['sleep', '10']) sys.exit(0) Run the above and you'll see Popen() _doesn't_ block the code flow. You must be doing something else strange. Maybe you don't care about blocking the GUI, but you certainly care about understanding what's wrong. How I monitor the clock: Every 5 seconds I call time.gmtime() and check the hour and minute. When those correspond with the waiting schedule, the tuning a recording sequence starts. Can't you run gobject.timeout_add_seconds() _with_ the number of seconds which the recording must last?! Anyway your solution seems reasonable also to me. Pietro westli --- On Sat, 1/23/10, Pietro Battiston too...@email.it wrote: From: Pietro Battiston too...@email.it Subject: Re: [pygtk] gobject.timeout_add() To: PYGTK pygtk@daa.com.au Date: Saturday, January 23, 2010, 5:51 AM Il giorno ven, 22/01/2010 alle 21.44 -0800, dj ha scritto: Thank you John and Pietro for your observations and advice. Because of them, I did some rethinking of my program. Threading has worked okay for a couple of years in this program as I continually improved it. But the GUI I started with had to be useful while recordings were taking place. I use the to tune a radio receiver according to a schedule and record what was found there, and I needed to be able to make adjustments on the fly. I use a different radio and GUI now, and except for Start and Quit buttons, the GUI is just to supply information. So I don't need threading or the timeouts to pause the program until the recording is finished. I'm not thrilled with seeing the GUI go dark during recording, but it's okay. Notice I was not at all suggesting to you to block the GUI... How do you call your external processes? Now there is only one 5-second timeout to check the clock between scheduled recordings. Is there a better way to monitor the clock? I have to use time-of-day rather than time periods, and I haven't figured out a better way than executing time.gmtime() every 5 seconds. I unfortunately cannot understand _what_ type of monitoring you need, and hence how you are currently implementing it. Pietro westli --- On Thu, 1/21/10, Pietro Battiston too...@email.it wrote: From: Pietro Battiston too...@email.it Subject: Re: [pygtk] gobject.timeout_add() To: pygtk@daa.com.au Date: Thursday, January 21, 2010, 1:56 PM Il giorno gio, 21/01/2010 alle 08.56 +0100, John Stowers ha scritto: On Wed, 2010-01-20 at 21:22 -0800, dj wrote: I hope this is the right place to ask this... I have a python program (using Glade to create the gui) that periodically launches ecasound to make audio recordings of various lengths. In order to keep the gui viable, ecasound runs in a separate thread. In order to keep the program from getting ahead of itself and trying to launch ecasound before the current recording process has finished, I use gobject.timeout_add() for the length of the recording (plus a second or two for safety). Most of the calls to gobject.timeout_add() are in separate functions with different intervals. All but one of them work. The last one only works if gobject.timeout_add(..., ...)/return False is appended to the end of the function that needs it, rather than calling it. This doesn't sound like a particuarly nice design, More specifically: are you sure you need threads at all?! subprocess.call will block the GUI, but subprocess.Popen won't. Pietro
Re: [pygtk] gobject.timeout_add()
Il giorno ven, 22/01/2010 alle 21.44 -0800, dj ha scritto: Thank you John and Pietro for your observations and advice. Because of them, I did some rethinking of my program. Threading has worked okay for a couple of years in this program as I continually improved it. But the GUI I started with had to be useful while recordings were taking place. I use the to tune a radio receiver according to a schedule and record what was found there, and I needed to be able to make adjustments on the fly. I use a different radio and GUI now, and except for Start and Quit buttons, the GUI is just to supply information. So I don't need threading or the timeouts to pause the program until the recording is finished. I'm not thrilled with seeing the GUI go dark during recording, but it's okay. Notice I was not at all suggesting to you to block the GUI... How do you call your external processes? Now there is only one 5-second timeout to check the clock between scheduled recordings. Is there a better way to monitor the clock? I have to use time-of-day rather than time periods, and I haven't figured out a better way than executing time.gmtime() every 5 seconds. I unfortunately cannot understand _what_ type of monitoring you need, and hence how you are currently implementing it. Pietro westli --- On Thu, 1/21/10, Pietro Battiston too...@email.it wrote: From: Pietro Battiston too...@email.it Subject: Re: [pygtk] gobject.timeout_add() To: pygtk@daa.com.au Date: Thursday, January 21, 2010, 1:56 PM Il giorno gio, 21/01/2010 alle 08.56 +0100, John Stowers ha scritto: On Wed, 2010-01-20 at 21:22 -0800, dj wrote: I hope this is the right place to ask this... I have a python program (using Glade to create the gui) that periodically launches ecasound to make audio recordings of various lengths. In order to keep the gui viable, ecasound runs in a separate thread. In order to keep the program from getting ahead of itself and trying to launch ecasound before the current recording process has finished, I use gobject.timeout_add() for the length of the recording (plus a second or two for safety). Most of the calls to gobject.timeout_add() are in separate functions with different intervals. All but one of them work. The last one only works if gobject.timeout_add(..., ...)/return False is appended to the end of the function that needs it, rather than calling it. This doesn't sound like a particuarly nice design, More specifically: are you sure you need threads at all?! subprocess.call will block the GUI, but subprocess.Popen won't. Pietro ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.timeout_add()
Thanks for your continued help on this, Pietro. Here is a very basic look at what the program does: 1. At a specified time, tune the radio and launch ecasound to make a recording. 2. After the recording has finished, tune the radio to another frequency and launch ecasound again. The version of the program I had been using launched ecasound in a thread so that the GUI would not be blocked. gobject.timeout_add() was used to stop the program from immediately re-tuning and trying to record again before the previous recording was finished. This happens hourly plus an additional 0-4 schedules within each hour. When I tried to add another schedule within the hour, I couldn't get gobject.timeout_add() to work with it. The threaded version uses os.system() to launch ecasound. I've been experimenting with subprocess.Popen and subprocess.call in the non-threaded version, but I don't understand those too well, and they both block the GUI. I understand that nobody has suggested that I block the GUI, but I can live with that as long as the rest of the program works. How I monitor the clock: Every 5 seconds I call time.gmtime() and check the hour and minute. When those correspond with the waiting schedule, the tuning a recording sequence starts. westli --- On Sat, 1/23/10, Pietro Battiston too...@email.it wrote: From: Pietro Battiston too...@email.it Subject: Re: [pygtk] gobject.timeout_add() To: PYGTK pygtk@daa.com.au Date: Saturday, January 23, 2010, 5:51 AM Il giorno ven, 22/01/2010 alle 21.44 -0800, dj ha scritto: Thank you John and Pietro for your observations and advice. Because of them, I did some rethinking of my program. Threading has worked okay for a couple of years in this program as I continually improved it. But the GUI I started with had to be useful while recordings were taking place. I use the to tune a radio receiver according to a schedule and record what was found there, and I needed to be able to make adjustments on the fly. I use a different radio and GUI now, and except for Start and Quit buttons, the GUI is just to supply information. So I don't need threading or the timeouts to pause the program until the recording is finished. I'm not thrilled with seeing the GUI go dark during recording, but it's okay. Notice I was not at all suggesting to you to block the GUI... How do you call your external processes? Now there is only one 5-second timeout to check the clock between scheduled recordings. Is there a better way to monitor the clock? I have to use time-of-day rather than time periods, and I haven't figured out a better way than executing time.gmtime() every 5 seconds. I unfortunately cannot understand _what_ type of monitoring you need, and hence how you are currently implementing it. Pietro westli --- On Thu, 1/21/10, Pietro Battiston too...@email.it wrote: From: Pietro Battiston too...@email.it Subject: Re: [pygtk] gobject.timeout_add() To: pygtk@daa.com.au Date: Thursday, January 21, 2010, 1:56 PM Il giorno gio, 21/01/2010 alle 08.56 +0100, John Stowers ha scritto: On Wed, 2010-01-20 at 21:22 -0800, dj wrote: I hope this is the right place to ask this... I have a python program (using Glade to create the gui) that periodically launches ecasound to make audio recordings of various lengths. In order to keep the gui viable, ecasound runs in a separate thread. In order to keep the program from getting ahead of itself and trying to launch ecasound before the current recording process has finished, I use gobject.timeout_add() for the length of the recording (plus a second or two for safety). Most of the calls to gobject.timeout_add() are in separate functions with different intervals. All but one of them work. The last one only works if gobject.timeout_add(..., ...)/return False is appended to the end of the function that needs it, rather than calling it. This doesn't sound like a particuarly nice design, More specifically: are you sure you need threads at all?! subprocess.call will block the GUI, but subprocess.Popen won't. Pietro ___ pygtk mailing list py...@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list py...@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list py...@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo
Re: [pygtk] gobject.timeout_add()
Il giorno gio, 21/01/2010 alle 08.56 +0100, John Stowers ha scritto: On Wed, 2010-01-20 at 21:22 -0800, dj wrote: I hope this is the right place to ask this... I have a python program (using Glade to create the gui) that periodically launches ecasound to make audio recordings of various lengths. In order to keep the gui viable, ecasound runs in a separate thread. In order to keep the program from getting ahead of itself and trying to launch ecasound before the current recording process has finished, I use gobject.timeout_add() for the length of the recording (plus a second or two for safety). Most of the calls to gobject.timeout_add() are in separate functions with different intervals. All but one of them work. The last one only works if gobject.timeout_add(..., ...)/return False is appended to the end of the function that needs it, rather than calling it. This doesn't sound like a particuarly nice design, More specifically: are you sure you need threads at all?! subprocess.call will block the GUI, but subprocess.Popen won't. Pietro ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.timeout_add()
On Wed, 2010-01-20 at 21:22 -0800, dj wrote: I hope this is the right place to ask this... I have a python program (using Glade to create the gui) that periodically launches ecasound to make audio recordings of various lengths. In order to keep the gui viable, ecasound runs in a separate thread. In order to keep the program from getting ahead of itself and trying to launch ecasound before the current recording process has finished, I use gobject.timeout_add() for the length of the recording (plus a second or two for safety). Most of the calls to gobject.timeout_add() are in separate functions with different intervals. All but one of them work. The last one only works if gobject.timeout_add(..., ...)/return False is appended to the end of the function that needs it, rather than calling it. This doesn't sound like a particuarly nice design, but I can't immediately think of what the problem is. You should post your code so others can take a look. In general however, you should remember * Be careful using threads and PyGtk+ * gobject.timeout_add is not guaranteed to be millisecond precise John ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
[pygtk] gobject.timeout_add timeout recalculation
In my application, I am using gobject.timeout_add to trigger periodic updates of the status of a number of machines. However, I am having a bit of trouble understanding exactly how the timeout is calculated. According to the documentation: After each call to the timeout function, the time of the next timeout is recalculated based on the current time and the given interval (it does not try to 'catch up' time lost in delays). The After each call to the timeout function,... leads me to think that the timer is reset when the timeout function returns. However, the phrase (it does not try to 'catch up' time lost in delays). makes me think that the timer is reset as soon as the timeout function thread is started. (This also seems to be confirmed by tracing my code) What I would like to happen is that the timeout gets recalculated when my timeout function is done/returns. I guess, I could add a new timeout from within my timeout function and have it [the timeout function] return False (so the old timeout is destroyed) but I am thinking that there has to be a better way to do this. I appreciate any advice on the matter. -- Mitko Haralanov == A Fortran compiler is the hobgoblin of little minis. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gobject.timeout_add timeout recalculation
Mitko However, I am having a bit of trouble understanding exactly how Mitko the timeout is calculated. According to the documentation: Mitko After each call to the timeout function, the time of the Mitko next timeout is recalculated based on the current time and Mitko the given interval (it does not try to 'catch up' time lost Mitko in delays). Mitko The After each call to the timeout function,... leads me to Mitko think that the timer is reset when the timeout function returns. Mitko However, the phrase (it does not try to 'catch up' time lost in Mitko delays). makes me think that the timer is reset as soon as the Mitko timeout function thread is started. (This also seems to be Mitko confirmed by tracing my code) I believe it works like this: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now ... If X is 2500ms and your callback takes 2ms to execute, the interval between successive calls will actually be 2502ms. Mitko What I would like to happen is that the timeout gets recalculated Mitko when my timeout function is done/returns. I guess, I could add a Mitko new timeout from within my timeout function and have it [the Mitko timeout function] return False (so the old timeout is destroyed) Mitko but I am thinking that there has to be a better way to do this. In our applications we added an abs_timeout_add function which takes hour, minute, second and microsecond. The callback is called at the same time each day by taking into account the runtime of the callback. You could do something similar with a shorter period. Skip ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gobject.timeout_add timeout recalculation
On Thu, 15 May 2008 18:48:22 -0500 [EMAIL PROTECTED] wrote: I believe it works like this: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now call your callback if it returned true: set wakeup for X milliseconds from now ... If X is 2500ms and your callback takes 2ms to execute, the interval between successive calls will actually be 2502ms. Unfortunately, it is how it work. In fact, that how I would like it to work. Here is what my testing shows: t0: set wakeup for X milliseconds from now t0+X: set wakeup for X milliseconds from now (t0+X+X) call callback if it returned true: noop else: delete the timer Here is an example: #!/usr/bin/python import gtk import gobject import time def callback (timeout): print callback called at: %s%time.time () time.sleep (timeout) print callback returning at: %s%time.time () return True if __name__ == __main__: gobject.timeout_add (20*1000, callback, 10) gtk.main () If you run this, you get: callback called at: 1210897497.69 callback returning at: 1210897507.69 callback called at: 1210897517.69 callback returning at: 1210897527.69 callback called at: 1210897537.69 callback returning at: 1210897547.69 callback called at: 1210897557.69 Note that the time difference between the callback returning at and callback called at is not 20 seconds but 10 seconds (20 second timeout - 10 second callback runtime). -- Mitko Haralanov == A programming language is low level when its programs require attention to the irrelevant. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gobject.timeout_add timeout recalculation
If X is 2500ms and your callback takes 2ms to execute, the interval between successive calls will actually be 2502ms. Mitko Unfortunately, it is how it work. In fact, that how I would like ^ not? Mitko it to work. Here is what my testing shows: Hmmm... It would appear the documentation is wrong. I thought in the past I remember seeing it work the other way. I can't reproduce it with the versions I have installed (2.6 and 2.10 at work and 2.12 at home). I'm installing gtk 1.2.10 on my Mac now. I'll see how it works there. (If I can get it installed...) Skip ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] gobject.timeout_add() problems using speech-dispatcher
I am working on an Activity for the One Laptop Per Child project. As you may know, OLPC activities often use pygtk. My activity is for reading Project Gutenberg Etexts, and I have been asked to add text to speech to that Activity using speech-dispatcher. The idea is to have karaoke-style highlighting, so that as each word is spoken it is also highlighted in the text. This should help children learn to read. To do this I have to synchronize highlighting and speaking. Speech-dispatcher can do callbacks when it is finished speaking, so my plan was to use gobject.timeout_add() to call a function at regular intervals. This function would check a flag that would be set to True if speech-dispatcher was finished speaking. If True I would highlight and speak the next word, if false I would not. I would use speech-dispatcher callbacks to set the flag to True every time it finished speaking. What I found out was that speech-dispatcher would not consistently execute the callbacks. When I pointed this out to the speech-dispatcher mailing list one of the developers recreated my problem, then found that it he just executed my method in a loop rather than using gobject.timeout_add() that the code in speech-dispatcher worked perfectly and all callbacks got executed. He is convinced that using gobject.timeout_add() interferes with socket activities in other threads. I have forwarded his email below. Unfortunately, running that code in a loop is less than optimum. I need to be able to turn speech on and off, which I can't do in a simple loop. I need gobject.timeout_add() to work, or something similar, to get text to speech with highlighting. I would appreciate any suggestions you have to offer. James Simmons ---BeginMessage--- The code is attached. This is not an OLPC Activity but a standalone program I use to try out new features Hello James, I have tried to run the code you've sent and I can reliably reproduce the issue. I believe it has something to do with the way how you call speechd.client.speak() from inside the gtk loop, because outside of it, everything works normally (even in your application). I'm not familiar with PyGTK however, so I don't see what exactly is going wrong. I'll try to describe my findings in hope you or someone else will have someidea. As you describe, in your program, the SSIP Python interface often fails to deliver a callback to the client application (in fact, it freezes and no other communication with Speech Dispatcher is possible). The exact reason is that in self._socket.recv(1024) (socket.socket.recv()) fails to return although the logs of Speech Dispatcher prove some new data have been written to the socket. I found that this happens when cb_next_word is called as a callback from keypress_cb() via timeout_id = gobject.timeout_add(100, self.next_word_cb) but it doesn't happen, if I call it directly (around line 75): self.karaoke = True self.finished_flag = True #timeout_id = gobject.timeout_add(100, self.next_word_cb) while True: self.next_word_cb() time.sleep(0.1); return True This variant will reliably speak the whole document word-by-word with all the expected callbacks received. Another interesting observation is that the mentioned _socket.recv(1024) returns and correctly receives all the pending callbacks just after I hit CTRL-C on the python interpreter running ReadETextsActivity.py and thus kill the main program thread. Now, the _socket.recv() function in the python speechd library runs in a separate thread that is being launched from the Client object constructor. So apparently gobject.timeout_add() somehow disturbs socket opperations in other threads. It seems really strange to me and quite unlikely that the python bindings themselves would be responsible. With regards, Hynek Hanke ---End Message--- ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
