ppaalanen at gmail.com
Mon May 7 00:56:19 PDT 2012
On Sun, 6 May 2012 15:30:19 -0500
Gregory Merchan <gregory.merchan at gmail.com> wrote:
> I looking for a migration guide from X11 to Wayland. Most of my Google
> search results are real estate listings for properties with windows in
> Wayland, MA.
> I have just a few things I hope someone will help me with:
> 1. The X property mechanism was generic, so we could have ICCCM, MWM,
> EWMH, etc. properties without changing the X server. Will Wayland also
> have such a generic mechanism?
I have not heard of any plans for such generic mechanism, nor do I
think it is useful.
The window manager is the compositor and the server. No client can see
any other client via the Wayland protocol. So if you did have a
mechanism to set generic properties on surfaces or other Wayland
protocol objects, there would be nothing that could use them.
Well, except the server. But for the server to use them, it has to be
programmed to support them. And if it has to be programmed, you could
as well just define a Wayland protocol extension and forget about
generic properties in the base protocol. The benefit of this is, that
there is a standard way in the protocol to advertise the support for
extensions. The client will know, if a "property" is honoured or
ignored. As extensions are protocol, they are described in XML with
strict types, and the wayland library will handle and check the details
for you. It will also automatically provide an API to the clients,
where you use specific Wayland protocol objects instead of arbitrary
strings or numbers.
Granted, it will add a bit of code to the client for checking if an
extension is available before using it.
> 2. Was the work requested in this message ever done?
> . (I could work on this maybe later this month, if it's not done.)
They did have a meeting going over EWMH etc. and picking useful things
for TODO. I can't point to any specifics writings, though.
Some of it is done, but definitely not all that a modern desktop needs.
> 3. X11 famously abided by the rule of determining "mechanism, not
> policy". Is there a similar rule for Wayland?
I guess sort of. The Wayland core protocol is meant to be kept very
simple and likely also policy-free.
However, like Alex Wu said, the server is also the window manager,
which necessitates some protocol with policy. But that protocol will be
extensions, most notably shell extensions. We also do not want to
enable the kind of fighting that is possible in X, when the X server,
window manager, and clients disagree on something.
> 4. I'm concerned about the implications of this message:
> . It looks like policy was being written into Wayland, but maybe that
> discussion was about Weston?
Yes, that discussion is about Weston, and specifically desktop-shell.
None of that applies to Wayland core protocol.
Weston has shell plugins. A shell plugin is basically a window manager,
implementing all the window management policy and protocol. It is a
plugin, because it has to be part of the server.
The desktop-shell plugin is a window manager for desktops. There is
also a tablet-shell plugin, but it would need more love. The
desktop-shell plugin is accompanied with the desktop-shell client,
which in a separate process is resposible for GUI elements, like
backgrounds and panels.
The Wayland protocol extension specific to desktop-shell is wl_shell.
The name is misleading nowadays, since it is not really part of the
core protocol. Any client will use wl_shell for window management
There is also a desktop-shell protocol in desktop-shell.xml, but that
is a private extension reserved for the desktop-shell client
Weston and its plugins are just a reference implementation. There are
also other server implementations out there.
More information about the wayland-devel