Re: more on re- draw at end of re-size

[Havoc Pennington <hp redhat com>]

"tony K." <tony kwok 3web net> writes: 
> I would postulate the general problem differently:
> How can an application obtain an event (signal, etc...) 
> corresponding to the "mouse up" at the end of the
> window resize user-interaction sequence. 

No - even if you get that, your app will still lock up for a
while. It's a bad UI if the user can't let go of the button without
having to wait a while to use it again.

I'm sure it may be a reasonable hack for a simple app to do the "on
button release" thing, but it's hardly the root of the problem, it's
just a hack around the fact that your app locks up. In an ideal world,
no GUI should ever lock up, ever, for any reason, for any user-visible
amount of time. Of course avoiding this can be a lot of engineering,
and that's why lots of apps have this bug.

> If now appears to me GDK/GTK+ simply has no provision for such 
> an elementary GUI building block.
> Someone goofed at the design stage.  :(

It has nothing to do with GTK, it has to do with how X works. There is
no way for GTK to find out this information, because it simply gets a
lot of resize events, it doesn't get any information about those
button presses, and it doesn't get any information such as "that was
the last resize event." Window managers often allow resize via key
presses; in that case there wouldn't be a button press at all. Some
window managers may also allow resizing without holding the button
down. Literally the window manager can do whatever it wants, and all
GTK sees is "window is now a different size."

Anyway, I'm trying to be helpful by suggesting that instead of trying
to do this hack, which does not work under X, you try to keep the app
from locking up. That's the best solution I can think of. You can do
this with threads, incremental calculations, pipes and processes,
there are lots of ways to do it, depending on the app.

Havoc