Your mail to 'Chinese' with the subject
Re: [FZH] FAD ???????? Ready
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post to moderated list
我发送到fedora china的每个邮件都显示被hold，请问list moderator能否批准一下，另外出现这种情况的原因是什么？
---------- 转发的邮件 ----------
发件人： Giovanni Campagna
主题： Mutter and Wayland
收件人： Gnome Shell List <gnome-shell-list(a)gnome.org>
I should have written this mail earlier, but anyway: at the Desktop
Summit 2011 there was a BoF on KWin/Plasma and Wayland. Attendees were
members of the KDE community (including the maintainer of KWin), me
(kind of representing GNOME), and Benjamin Franzke from the Wayland
We discussed the necessary developments of the wayland protocol to fully
replace X11, and I think they may be interesting to you as well.
First of all, client side windows won't happen. KWin will never-ever
have it, at the cost of sticking a secondary title-bar on top of the
client-drawn one. The KDE use case for this is different decorations
under the different environments they target (desktop, netbook, mobile).
I explained the gnome-shell use case (different decorations in workspace
view and in the activities overview).
Also, the main advantages of client-side decorations (tabs on top,
toolbars, menus) are not seen as advantages, as they reduce consistency
among apps and facilitate developer "creativity". I think I agree on
this. For the specific case where this is desirable (like Firefox menu),
a new protocol could be devised between the compositor/wm and the app to
represent the menu (dbusmenu? GActions?), which btw would allow the
shell to place it inside the App Menu.
In any case, further discussion on this topic, in particular with the
wayland devs, which so far have been supportive of c-s-d, should happen
on the wayland-devel mailing list at freedesktop.org.
Second important point: Martin doesn't want to port KWindows
(K-equivalent of libwnck) to wayland, and as a result, much of the
functionality of EMWH won't have a wayland equivalent. The only parts
covered by wayland natively (as part of wl_shell, probably) will be
client-to-compositor coordination (wm_title, wm_state, restacking,
handling focus, move-resizing, etc.), whereas all the dock/tray related
stuff will be exported by KWin to Plasma using a private DBus interface.
We discussed coordinating this interface, for the benefits of
cairo-dock, awn, docky and the like, but at the moment they don't feel
it would be stable enough. Since the other major compositors
(mutter/gnome-shell and compiz/unity) already handle the shell parts in
process, this isn't immediately needed. The GNOME fallback case is not
affected as wayland is GL only, and metacity would still run on X11.
Third point: as I was the only GNOMEr attending, I presented myself as
"interested in porting mutter to wayland", and so I started. So far all
my work has been towards separating the X stuff from the general window
management. It lives in a branch at my local repo, but I can publish in
github if someone wants to see it. It's not guaranteed to work, although
I tried to make every commit buildable.
If on the other hand, someone else has started (or is planning to start)
this work, I think we can coordinate. Of course, this is 3.4/3.6 matter.