Re: gtkwindow changes

[Havoc Pennington <hp redhat com>]

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.

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

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

This allows you to e.g. have the model modify the request to set foo,
and it also ensures that your code correctly handles the case where a
third party modifies foo. Because you go through the same foo_changed
codepath regardless of who did the setting of foo.

This gives us a nice simple setup with a single codepath and a clear
way that it's supposed to work. If you start doing the
assume_foo_is_10() thing then you have race conditions, possible
infinite loops, multiple codepaths, and so on.

X window management simply works this way, we have to live with it.

> > This would be OK for override redirect windows,
> 
> no it can't be ok for any type of window as long as gdk_window_resize(toplevel)
> doesn't store away newwidth/newheight.

I'm saying it would be OK for override redirect if we stored the new
width/height immediately for them.
 
> > And updating the GdkWindow size immediately would also be OK for
> > override redirect windows.
> 
> can you explain why you think override redirect windows should be any
> different here than normal windows?

Because we can declare the canonical location of the window size state
to be on the client side, and then sync it to the server. i.e. we can
be the "model."

We can't do this for managed windows, because we can't reliably sync
the server-side information to the client-side information. Instead,
we are the "view" and are listening to the server-side window state.
 
> GTK_RESIZE_IMMEDIATE is actually about resizing speed, unrelated to
> configure event handling in gtkwindow.c code. there's no particular reason
> for GLE selector to be GTK_RESIZE_IMMEDIATE other than that way i got
> at least one window that tests whether GTK_RESIZE_IMMEDIATE still works
> in gtk.

I think we should simply disallow GTK_RESIZE_IMMEDIATE on toplevels;
or at minimum, for non-override-redirect toplevels. It is _wrong_ to
assume we can resize immediately; X toplevel resizing is
_asynchronous_ and there is no way around it.

My suggestion would be either:

 a) g_return_if_fail () in set_resize_mode if you try to make a
    toplevel immediate

 b) say that the canonical location of window size is client-side for
    override redirect windows, and allow resize immediate for
    GTK_WINDOW_POPUP. Change gdk_window_resize() for override
    redirect.

However I think b) is a useless feature that causes a lot of
complexity. Unless you can suggest a use for it?

Havoc