Re: implementing a delayed "busy" cursor
- From: Paul Fox <pgf foxharp boston ma us>
- To: gtk-list gnome org
- Subject: Re: implementing a delayed "busy" cursor
- Date: Mon, 06 Aug 2007 08:16:32 -0400
robert pearce wrote:
> On Sun, 05 Aug 2007 14:02:22 -0400 you wrote:
> > 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.
okay -- i'll look into g_idle_add. i'm somewhat limited in that i'm
only dealing with a thin shim of code between gtk underneath, and an
app that supports gtk/gtk+/qt/qt4 plus win32. so major architecture
changes won't happen, at least not overnight. :-)
but i think i understand the directions in which we need to move
(i.e., smaller chunks, more yields) to make this work.
thanks to all respondents.
paul
=---------------------
paul fox, pgf foxharp boston ma us (arlington, ma, where it's 64.4 degrees)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]