Re: gtkwindow changes
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Havoc Pennington <hp redhat com>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: gtkwindow changes
- Date: Fri, 17 Aug 2001 20:42:40 +0200 (CEST)
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]