client side decorations

Michal Suchanek hramrach at
Wed May 11 02:22:45 PDT 2011

On 6 May 2011 21:14, cat <zixon65 at> wrote:
>> "Window management policy" should also be client-side. I may not have been
>> clear about that. The wayland compositer almost NEVER moves or raises or
>> resizes a window. Clients do this in response to clicks or whatever. This
>> would have made it TRIVIAL to implement Gimp the way they intended, as at no
>> time would an image window raise above their toolbars, since they control
>> both of them.
> I wouldn't use wayland if thats the case, the kind of security risk this
> creates is massive. you could have clients that refuse to cooerate and

There is no security risk in allowing the Gimp to position its window
relative to each other.

You can see a half-hearted example of this on OS X. You can click the
dock icon of a running application to raise all its windows above
other applications but the z-order among the windows of the single
application is preserved.

> always take up the entire screen, or worse, rendering your computer useless.

This is completely possible regardless of allowing z-order changes.

AFAIK there is nothing stopping any application from creating several
windows per second which will automatically get on the top in z-order
and nothing stopping it from creating so large windows it will
effectively kill the compositor (either by means of OOM killer or by
means of swapping it out and having it run on swap.

> also I never like muti window apps like the gimp, or openoffice. they draw
> your attention away from what your doing to rearrange these little windows,
> and what ever you do don't close them or would could spend the next hour
> trying to get them back. there sould always be central system for making
> windows behave or they won't

The problem with multi-window applications is that multi-window UI is
not really well supported neither in Windows nor in X-windows so you
always get bad experience.



More information about the wayland-devel mailing list