Re: gtkwindow changes

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 17 Aug 2001, Owen Taylor wrote:
> 
> > 
> > Tim Janik <timj gtk org> writes:
> > 
> > > On 17 Aug 2001, Havoc Pennington wrote:
> > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Tim, I'm not sure about adding this in gtk_window_move_resize():
> > > > 
> > > >   window->need_default_position = FALSE;
> > > > 
> > > > it's sort of a bad hack. Can you explain what the loop is that you're
> > > > trying to fix? I think we can probably fix it more nicely.
> > > 
> > > if you have an immeditely resizing container, your code to reset
> > > need_default_position in map() was never triggered, we'd get
> > > into endless recursion from move_resize.
> > > for a test, revert gtkwindow.c to before my commit and click
> > > on GLE's selector button, it'll just segfault on stack overflow
> > > from recursion in gtk_window_move_resize().
> > > (that's also why i added some comments about IMMEDIATE resize containers
> > > so we keep that in mind for future changes).
> > 
> > Hmm, was it even intended that you could set a toplevel window to
> > RESIZE_IMMEDIATE? The potential for causing yourself serious problem
> 
> well, we started out with gtk having RESIZE_IMMEDIATE being the only possible
> resizing policy and at some point added the ability to handle resizes from
> an idle handler. we never had a reason to disable RESIZE_IMMEDIATE for
> toplevels, and in fact 1.2 still works fine with that kind of setup.

Actually, I believe 1.0 had only resize queing on the toplevel, and no
ability to disable it. I'd have to go to the code to check that
however.

We added RESIZE_QUEUE for GTK+-1.2 because it was needed for GtkViewport.

I think we added RESIZE_IMMEDIATE just because it was easy enough and
we sort of thought it might be useful for something.
 
> > with this is quite high.
> 
> why so? the bug hit in gtk_window_move_resize() was introduced recently,
> what serious problems are you thinking about?

If you don't have queued resizes, your performance is miserable.
We queue_resize() all over the place...
 
> > Is there a good reason for doing so?
> 
> is there a good reason not to?
> considering that usually all containers but GtkWindow have RESIZE_PARENT
> set on them

Not GtkViewport.

> questioning RESIZE_IMMEDIATE for GtkWindow is more about
> questioning set_resize_mode() in general, so far i've not come across
> good reasons to disable RESIZE_IMMEDIATE, if you have any, describe them.
> note that gtk_window_move_resize() usually handles RESIZE_IMMEDIATE quite
> fine. in the case where we defer widget tree resizes upon issueing
> gdk_window_resize() until we receive the configure event, we just meant
> to take advatage of the resize queueing facility. in general, code
> shouldn't rely on resizes occouring asyncronously.
 
There should never be any reason to have to justify why you should
_not_ add extra complications. If there is no reason to do something,
than it shouldn't be in there, since you have:

 - Made your interfaces more complex

 - Made your code more complex, and added new possible bugs.
   Code paths that nobody ever uses are the perfect breeding ground
   for bugs, as you've demonstrated by using RESIZE_IMMEDIATE
   in GLE.

Regards,
                                        Owen