Re: [gtk-list] Re: coordinating idle events and redraws

[Marc Ewing <marc redhat com>]

Owen Taylor <owt1@cornell.edu> writes:
> 
> 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.

Ah, so the GTK system *itself* is using the idle queue to handle
redraws.

> 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...

I agree.  Either that or two distinct idle queues, one for
GTK, and one for the app which only runs when the GTK idle
queue is empty.

Perhaps only two priorities are needed, one for internal
handlers and one for application level handlers?

> > 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.

I guess what I was getting at was the original problem in a different
way.  Since GTK and the app were sharing the same idle queue, to
the *app* its idles handler didn't seem to happen at idle.

I'd be happy to generate a patch to add priorities to the idle
handlers, if that what you think is the right thing to do.
Just let me know.

Thanks,
Marc