Re: gtkwindow changes



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.

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

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

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]