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 devs. 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. Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part