microcai microcai at fedoraproject.org
Thu May 5 07:48:23 PDT 2011


于 2011年05月05日 22:13, cat 写道:
> I thought the compositor would/could provide decoration. the compositors are
> after all their own projects as wayland is a protocol, and if you haven't
> noticed, most metacity/emrald themes are just a set of pictures, would it be
> bad if the compositor had the ability to handle images from files? i don't
> think that compositor handled decorations would be too much. this is
> something else that could be handled by a flag.

WTF are you argue about?

1) Compositor based decorations does not prevent you from doing client
side decorations.

2) Client side decoration is still able to recover from lock up. See how
windows can close in-response window.


>
> On Thu, May 5, 2011 at 8:33 AM, Sam Spilsbury <smspillaz at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list