Re: implementing a delayed "busy" cursor
- From: Robert Pearce <rob bdt-home demon co uk>
- To: gtk-list gnome org
- Subject: Re: implementing a delayed "busy" cursor
- Date: Sun, 5 Aug 2007 21:37:39 +0100
Hi Paul,
On Sun, 05 Aug 2007 14:02:22 -0400 you wrote:
> thanks -- i'll do some reading. at the moment, i'm not sure how
> this will work. if i set a gtk timeout for 1 second, but my
> program's "think" time is 10 seconds, then i won't get back to
> the event loop until after that, and i've therefore blown my
> intended timeout.
If your program is doing something that will take it 10 seconds, you
need to adjust your architecture to shift that operation out of the
loop. Either:
- Split the big think into lots of little chunks
- Let the GTK main loop get a shot in between them
or:
- Move the complex thinky bit into another thread
- Send a completion notification when it's done.
For the first method you should use g_idle_add to put the iteration of
chunks into free time. This leaves GTK running properly and doing your
hard stuff when there's nothing else to update.
For the second, the rule of thumb is that only the main thread should
ever do a GTK call. Passing status from the worker thread can be done
in several ways, but it's not a GTK issue.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]