Re: gtkwindow changes

[Tim Janik <timj gtk org>]

On 17 Aug 2001, Havoc Pennington wrote:

> 
> Tim Janik <timj gtk org> writes: 
> > the only reason we cannot is gdk_window_resize(toplevel) not taking
> > over the new width/height right away, and i don't see a good reason for
> > it doing that.
> 
> Because the call can fail or be modified. There's no guarantee at all
> you'll actually get the new size.

right, but in most cases you actually get the size you requested, especially
since we have code that anticipates window manager constrains.

> > in general GTK_RESIZE_IMMEDIATE should work fine for any container,
> > including toplevels, as i replied to owen, code shouldn't rely on
> > resizing occouring asyncronously (at least up to now, if we want to
> > change that for the future, that's a different story).
> 
> As a general design principle, we need to know where the canonical
> location of a given piece of state is. For managed window size, this
> is on the server side, controlled by the window manager. 
> If you start trying to guess what the WM will do, then you end up with
> any number of race conditions and broken stuff.

this is not blindly guessing, we've requested a size and usually get that size.
and if if we don't, we still handle that case perfectly well, just like we
handle other arbitrary resizes perfectly well.

> i.e. you have one canonical location of state, and everyone else has
> to listen to change notifies on that state. 
> 
> It's the same reason that the following code is broken in the
> model-view-controller pattern:
> 
>   model_set_foo (model, 10);
>   assume_foo_is_10 ();
> 
> The correct code is:
> 
>   foo_changed_callback ()
>   {
>    if (foo is 10)
>      assume_foo_is_10 ();
>   }
> 
>   connect (model, foo_changed_callback);
>   model_set_foo (model, 10);

;) that's not the all-and-end of it, there're enough examples out there
that do:

model_set_foo (model, 10);
view_set_foo (view, 10); /* we know that most times we _get_ 10 from the model,
                          * and as model responses can take some time, updating
                          * here right away can greatly increase responsiveness
                          */
foo_changed_callback (new_foo)
{
  if (view->foo != new_foo)
    view_set_foo (view, new_foo);
}

why do you think there's code out there for various time consuming
tasks that implements precalculations and discarding mechanisms
for worst-case scenarios?

> 
> Havoc
> 

---
ciaoTJ