Re: gtkwindow changes

[Tim Janik <timj gtk org>]

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

note that with my changes, since i special cased queue_resize() to only
happen for RESIZE_QUEUE now, we shouldn't end up in an endless loop
even without window->need_default_position = FALSE; but that's actually
a bit questionable.
theoretically, for GTK_RESIZE_IMMEDIATE we should do the equivalent of
queue_resize there, which _should_ endup in the window->configure_notify_received
branch and just do size_allocate() + _draw(). obviously, that can't happen
since we haven't received the configure event, and doing:

      if (container->resize_mode == GTK_RESIZE_QUEUE)
        {
          gtk_widget_queue_resize (widget);
          _gtk_container_dequeue_resize_handler (container);
        }
+     else /* GTK_RESIZE_IMMEDIATE */
+       {
+         GtkAllocation allocation = { newwidth, newheight };
+         gtk_widget_size_allocate (widget, &allocation);
+         gtk_widget_queue_draw (widget);
+       }

can't yield correct results either, since gdk_window_resize(toplevelwindow)
doesn't poke the new width and height into GdkWindow until a configure
event is received, so drawing code that querries width/height from the
gdkwindow instead of widget->allocation will break.

i do think, we should take over newwidth,newheight in gdk_window_resize()
even for toplevel gdkwindows, usually it will be what we requested, and
if the window manager comes back with a different size, we do honour that
appropriately anyways. then we can do the intended
+     else /* GTK_RESIZE_IMMEDIATE */
+       gtk_widget_queue_resize (widget);
in gtk_window_move_resize(), but also need window->need_default_position
to be correctly reset in time.

i don't see resetting window->need_default_position = FALSE; in move_resize()
as a hack btw, there's no point in keeping that flag beyond actually requesting
a position.

> The other changes you applied look fine, I'm appending the patch for
> reference. I'm not sure you and Owen had actually agreed on the FIXME
> for the FIXME comment though.

i've outlined in my reply to owen's comments why we are not doing extra work
there (besides the FIXME i left). the case is similar to size_allocate,
if new_size!=old_size, we _have_ to redraw the whole widget.

> 
> Havoc
> 

---
ciaoTJ