Here's an excerpt from a module of miscellaneous pygtk functions.
It shows three platform-dependent implementations of an update()
function. update() is used e.g. to update a progress bar
in the middle of a time-consuming operation -- it's analogous to
the Tkinter update() function.
I haven't bothered looking at Gtk+ or pygtk sources in order to figure
out why you need threads_(enter|leave) on Solaris but not on Linux.
If somebody could explain the difference I'd be grateful.
One last note: This code was tested w. pygtk 0.6.2, on all
three platforms.
--
Mitch
[EMAIL PROTECTED]
-snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip-
# On IRIX we're running Gtk+ version 1.2.3. On Solaris and Linux we're
# running 1.2.6.
# On Linux, when performing a "manual" event loop to update the display,
# you gotta be careful to release the Gtk+ mutex by calling
# threads_(enter|leave). If you don't, the app will lock up when it
# checks for pending events.
# On IRIX, you can't call threads_enter, because we're using an old
# version of pygtk which doesn't expose the threads_(enter|leave)
# calls.
# On Solaris, you can't call threads_(enter|leave) because if you do
# the app will lock up when it checks for pending events.
#
# This all seems pretty bogus. But the following code works...
if sys.platform[:5] == "linux":
def update():
"""Update the UI: flush pending rqsts and process pending events."""
gtk.gdk_flush()
gtk.threads_leave()
while gtk.events_pending():
gtk.mainiteration(0)
gtk.threads_enter()
elif sys.platform[:5] == "sunos":
def update():
"""Update the UI: flush pending rqsts and process pending events."""
gtk.gdk_flush()
while gtk.events_pending():
gtk.mainiteration(0)
else:
# For IRIX w. Gtk+ 1.2.3:
def update():
"""Update the UI: flush pending rqsts and process pending events."""
# This solution was recommended on the pygtk mailing list,
# by Bernhard Herzog <[EMAIL PROTECTED]>, the author of Sketch.
# Speculation is that this is all due to a bug in recent versions
# of Gtk+, e.g. 1.2.3 - 1.2.6.
if hasattr(gtk, "gdk_flush"):
gtk.gdk_flush()
if hasattr(gtk, "threads_leave"):
gtk.threads_leave()
while gtk.events_pending():
gtk.mainiteration(0)
if hasattr(gtk, "threads_enter"):
gtk.threads_enter()
-snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip-
Mitch Chapman wrote:
>
> On Sat, 26 Feb 2000, Scott Bender wrote:
> > Actually, the hang came after my timeout function completed. It was calling
>mainiteration(FALSE) to
> > update a progress bar, which was causing the hang. Anyone know why?
> >
> > thanks,
> > - Scott
>
> I've seen this recently. The behavior varies depending on what version
> of Gtk+ you're running with, and on what operating system.
>
> The basic problem is that, on some platforms, even w. Gtk+ 1.2.6,
> you need to surround calls to gtk.events_pending() and
> gtk.mainiteration() with calls to gtk.threads_leave() and
> gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
