[Sam Spilsbury]

Client Side Decorations still have the fundamental problem that when
the client locks up, you're no longer able to close windows.

A better solution is to have the compositor put each client in their
own sub-compositor and have it draw the background of the window. This
way you get the consistency of having each window have the same
decorations, the client can shove whatever it wants in the decoration
area (since its window effectively starts at 0x00 and when the client
locks up, you're still able to do basic window management tasks on the
client.

On Thu, May 5, 2011 at 1:58 PM,  <maltee at lavabit.com> wrote:
> First of all, especially after reading through the mailing list for a bit,
> I think Wayland is an amazing project and I want to thank everyone
> contributing to it! Keep up the great work!
>
> I used to be against Client Side Decorations, but after reading through
> the mailing list, I'm starting to think this might actually be the way to
> go. But one (imho important) question remains unanswered: How are we going
> to maintain uniformity amongst decorations? My concern is rather the feel,
> than the look. Application windows look different anyway, but with X, all
> titlebars (with very few exceptions, such as chromium) look and behave
> roughly the same. Button orders of applications being different would have
> a huge impact on usability, even button sizes and exact positions is
> something to worry about. On a GTK+ based Desktop you probably want GTK+
> based window decorations. Qt applications will probably integrate the look
> and feel, so this won't be a problem. But what about applications that
> don't use a specific toolkit, such as games or X for wayland? I see no
> way, those would actually start using one of the major toolkits instead
> (which would be a very bad idea). Should everyone start implementing their
> own decorations, resulting in a decoration chaos? We definitely need some
> standard.
> Mac OS X and Windows don't have this problem because they each have a
> default toolkit most of the other available toolkits try to wrap/emulate.
> On Linux we have to deal with the advantages and disadvantages of variety
> with no standard. Inconsistency of decorations is nothing we should take
> for inevitable.
>
> Unfortunatly, I don't understand much of the subject, I might be talking
> rubbish, so please bear with me: My general idea is to define some sort of
> plugin API for decorations. Toolkits/Applications can provide their own
> decoration plugin which is used unless overridden and would integrate well
> with the application window. There might be a very simple default
> decoration provided by wayland. Applications can allow to replace their
> own decoration with something else (or test the desktops default for
> functionality and decide whether they want to use their own or not).
> Decorations can interact with Applications on ABI basis rather than
> protocol basis.
> + Decorations would integrate well with application windows for the
> majority of applications on the desktop
> + All decorations will have the same look&feel (with few exceptions)
> + Applications that do not use a specific toolkit would not have to
> implement their own decorations
> + Applications that want to do something fancy, like tabs (chromium) in
> the decoration can do so by extending the toolkit's decoration plugin so
> they will have something that looks similar to many other applications and
> they don't need to reinvent the wheel.
> + People who want something special can write their own decorations, just
> like people write their own window managers now.
>
> Maybe Client Side Decorations are the way to go, but not before the
> consistency issue is solved!
>
> Regards,
> Malte E.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury