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

[dg tao-group com]

[...]
> 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. 
>
> If now appears to me GDK/GTK+ simply has no provision for such 
> an elementary GUI building block.
> Someone goofed at the design stage.  :(

Not really. GTK has nothing to do with window resizing; it's the window
manager's job. All GTK is getting is an X event telling it that the window
state has changed (ConfigureNotify?). There's no way GTK *can* get this
information.

This *is* a window manager issue. An application shouldn't have anything to
do with any of this. I'd say that the correct solution in this case is to
have an interruptible drawing routine, so that whenever the window size
changes a bit (as the user drags it) the current draw-in-progress is aborted
and a new one started. This will give you better performance generally, too;
you're putting in lots of effort on the resize, but have you thought about
expose events? Someone dragging a dialogue box on top of your window?

If the application is still chugging, then the user can set its window manager
to wireframe resizes. But the application shouldn't force it onto the user.

-- 
+- David Given ---------------McQ-+ "For is it not written, wheresoever two or
|  Work: dg tao-group com         | three are gathered together, yea they will
|  Play: dgiven iname com         | perform the Parrot Sketch?" --- _Not The 9
+- http://wired.st-and.ac.uk/~dg -+ o'Clock News_