Re: coordinating idle events and redraws

[Owen Taylor <owt1 cornell edu>]

Marc Ewing <marc@redhat.com> writes:

> I've got a gtktree widget, which builds itself dynamically as you
> click on the entries, using the "expand" signal.  Some of these
> expansions take quite a while so the first thing I do is a
> gdk_window_set_cursor() to put up a watch cursor.  Then I go and
> do the expansion, making the new subtree, appending treeitems, etc.
> At the end I want to change the cursor back to normal.  If I do
> it right away, the cursor changes back to normal, and the the big
> redraw of the widget happens - wrong order.  So I set up a one time
> idle function to reset the cursor.  But, it appears that idle
> handlers are run *before* the queued up redraws for the widget.

The problem (I think) is that what is queued up initially is
not redraw requests but resize requests. Then you add your
idle handler.

The resize requests get run, and add an idle handler for the
redraw requests, your idler handler gets executed, then the
redraw idle gets executed.
 
> Is there any way to get a function to run *after* all the redraws?

No good one that I can think of right now. (I suppose you could
temporarily hook into the "draw" signal in one of the widgets and when
it gets called (after the redraw requests are being executed) remove
the handler and set up your idle handler.)

I think what is needed is priorities for the idle handlers.
By default, the resize and redraw handlers should have a higher
priority than the applications handlers, because from the
applications point of view GTK isn't idle until it has 
executed them. Going on the TODO list...
 
> On a similar note, the "idle" handlers seem to be misnamed.  They
> don't run on idle (ie when there are no other events/whatever to
> take care of) at all.  They run at the next gtk_main_iteration_do().

I don't see this in a quick test - I set up an idler handler for
a program and all the setup events got executed before the idler
ran for the first time. But it is possible something is going
wrong in more complex situations. "idle" handlers should be
behave as their named.

If you see idler handlers running they shouldn't, I'd like to
fix it. A test case would be great, but just description of
what you're doing when it occurs would be enough.

Regards,
                                        Owen