Re: [dev] Wayland

From: Hadrian Węgrzynowski <>
Date: Wed, 15 Feb 2012 16:36:24 +0100

On Wed, 15 Feb 2012 15:28:28 +0100
Eckehard Berns <> wrote:

>I might be wrong, but my biggest fear is that using Wayland means that
>I'm getting the current desktop paradigm shoved down my throat. If I
>understand this correctly something like dwm would be implemented in
>the compositor (for the window placement) and all clients at the same
>time (window decorations--or the lack thereof--are part of each
>client). It's not a simple program on the side any more.
>My guess is that the Wayland protocol will get bloated pretty quickly
>after the first release, since everyone will want their part of X back.
>And if it's not part of Wayland there will be more additional standards
>on Heck, the article mentions that currently Wayland
>has problems getting popup windows to work because Wayland doesn't
>support window positioning by the client! So they're already in the
>process of adding standards on top of Wayland.
>Again, I am nowhere near well enough informed, so my statements might
>be FUD.

How I understand it is that window decorations are part of compositor's

If they will leave window positioning unimplemented that can lead to
few things. It could be just good for dwm case - windows are positioned
as we see fit.

Making tray icons would be very simple (not that they are needed). In a
way every app could be in tray, like mplayer window (not usefull
example). Compositor then would only need a way to tell which windows
to put in tray. So how? Extend Wayland? Use dbus? I doubt that they
will go with some simpler way.

Brain dead extensions can go to dbus leaving Wayland quite clean, but
some apps broken.

Few things that I would like to know:

1. Will embedding be supported? Could we implement tabbed in Wayland
or would it be compositor's (future dwm's) job? Or maybe it would lead
to external protocol for embedding?
2. Is there suckless rendering library? :) There was once thread about
that in hypothetical Wayland dwm or suckless widget toolkit
3. Input handling would come from evdev - using kernel interfaces? Will
it be filtred by compositor to handle i.e. wm keybindings?

It could be good exercise to make static Weston and all other things to
check our case. Maybe it will be simpler than with X...
Received on Wed Feb 15 2012 - 16:36:24 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 15 2012 - 16:48:04 CET