A dock for Wayland Author fabounet, Saturday 21 June 2014 à 14:15 Note Comments 15 Cairo-Dock has now a basic Wayland support.

Don't jump for joy too fast, it's really as basic as you can get.

But it highlights some interesting points, as a developper and as an user.





Cairo-Dock in Weston 1.5, with some desklets





Cairo-Dock in Weston 1.5 with the Applications Menu



What's nice

The dock and the overall desktop is quite fluid with the free drivers.

For the end-user though, but Weston is more a proof of concept and not meant to be used as your daily environment.

For the developpers however, Wayland is quite attractive, mainly because the dreadful X server-client message mechanism has been replaced by a clean collection of proxy objects (which also means it's a lot easier to extend the protocol).



What's wrong

Window placement The biggest concern I have is that there is no window placement on the client side: an application can't position its window(s) to a given place on the desktop.

This is a serious issue: for instance, desktop widgets can't be placed on the desktop, you have to move them manually each time you start a session.

For the developpers, it means we have to reverse-engineer the placement algorithms of every applications to use relative coordinates (for instance, to position a menu at a given place).



Which is leading us towards some ugly hack, like adding a ' set_panel_position ' method, to allow a panel to be placed where it wants (at some predefined positions).



Also, no equivalent of strut partial (the zone that maximized windows can't overlap); Weston supposes that a panel automatically defines a strut given by its dimensions, which is obviously wrong in the case of an auto-hiding panel or a dock that can zoom.

Hence maximized windows being not placed correctly.



It seems Wayland wants to outsmart the applications developpers, and so far the result is not convincing at all.



The desktop shell The other big concern is about the desktop shell .

It's the interface the compositor offers to applications wanting to interact with the desktop.

As much the compositor part is refined, as much this part is very much in-progress.



For instance, there is still no way to access the list of surfaces (=windows) and manipulate them from another application, which means no taskbar .

Or more precisely, only the Compositor can do the job.

And not only this job, but a lot of others too, like changing the resolution, adding/removing a workspace dynamically, etc.

Note also that having global shortkeys is impossible (as you can see on the pictures in the terminal).

A wayland compositor just doesn't expose enough of its internals (is it for security ? it's way too extreme then), making it a hostile environment for third-party tools.



Because of that, Mir may be ready for the desktop before Wayland (at least they have already planned to expose a taskbar API through BAMF ), which makes their move much more understandable.



I'll let aside some other bugs I could see, like artefacts in the menus (visible on the pictures), wrong mouse position on Leave/Enter events, or EGL being linked to GLX only in the current packages; I'm confident that they will be fixed quickly.



Conclusion

We definitely need a replacement for X (it doesn't fit well on smartphones, cars, etc), but on the desktop Wayland is currently missing too many features. Let's not forget that the good reasons (like security) will be of no help if people don't use the product. And they will not if the user experience is not superior or equal as with X (and I'm not talking about having smooth transitions between the desktop and the tty consoles).



Also, let's hope that all these efforts put into porting everything to Wayland will not eclipse some other problems, cheaper and yet important, like Gnome adopting the StatusNotifier protocol, or having a portable global menu .



Want to test ? Install the latest build of Cairo-Dock, Wayland and Weston.

Add your user to the weston-launch group, then go to tty1 , and type weston-launch .

Open a terminal.

Now start a session bus if not already done (this is not required, but several applets make use of Dbus):

/usr/bin/dbus-daemon --session --address=unix:path=/tmp/dbus-session-socket&

and export the socket name:

export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-session-socket

Finally, launch the dock:

cairo-dock



Fabounet. Tags :

matttbe, Sunday 22 June 2014 à 11:41 @fabounet : Very nice job

Thank you!

Guest, Sunday 22 June 2014 à 11:55 Works great with Gnome 3.12 on Wayland, too.



http://i.imgur.com/KjJHMm9.png

matttbe, Sunday 22 June 2014 à 12:00 Nice

Guest, Sunday 22 June 2014 à 12:25 Very nice indeed !

However I don't really get the criticism against Wayland and especially the comparison with Mir here. Mir/Unity 8 still hasn't shown any sign of basic window management yet, which is really not trivial especially if you want to avoid security concerns, and we still have no real idea how this will go or work so it's really premature to say that.

The Wayland protocol might be a bit too restrictive compared to X but nothing prevents Wayland compositors to agree on mechanisms or APIs to let docks or other applications get access to the required features in a safe manner. Standardization work is already on the way with xdg-shell for example.

fabounet, Sunday 22 June 2014 à 15:11 Ubuntu has BAMF, which exposes all the needs for a taskbar through Dbus. I believe they will keep it with Mir, that would be the logical way to go for them.



On the Wayland side however, there is clearly no API yet, and xdg-shell is not what's going to save us. xdg-shell is meant for clients to manage their own windows (and by the way, xdg-shell doesn't let you place your window where you want by design , that's one of the blocking point I mention in the article), what we need here is a good desktop-shell interface to let a client act on the desktop and the windows.



Criticim is especially important now because once the protocol is frozen it will be harder to make it evolve. Don't get me wrong, I'm really excited to have a new tool like that, and I think third-party projects like us can bring a useful feedback to the Wayland developpers.

Guest, Sunday 22 June 2014 à 15:53 Thanks for the answer.



We'll see what the future brings but there's no reason that third-party docks won't play nicely with Wayland. It's still early days for W.

Guest, Monday 23 June 2014 à 00:51 Any variables I need? Nothing seems to appear when I run under Weston:



I already have

export GDK_BACKEND=wayland

export CLUTTER_BACKEND=wayland

export COGL_RENDERER=egl_wayland



Thanks

Guest, Monday 23 June 2014 à 04:59 Never mind, I forced egl with cmake, and it works

fabounet, Monday 23 June 2014 à 21:19 Do you have an EGL lib compiled against wayland ? because on Ubuntu 14.04 it's compiled against GLX so I couldn't use the OpenGL it under Weston.

Also, note that the dock will appear at a random place each time, since the window placement is impossible with Wayland (at least with the 1.5 and gtk 3.12), so sometimes it appears completely out of the screeen (!).

Guest, Wednesday 25 June 2014 à 18:16 The problem is not wayland but weston that does not have all the interfaces (libraries from X)

https://imgur.com/H5pLvI2

Here you can see cairo dock running on a gnome-shell wayland session where you can set window placement using X and mutter the wayland compositor places the windows where they should be. Of course this depends on X11 which weston avoids

fabounet, Wednesday 25 June 2014 à 19:43 The Wayland protocol does not allow window placement by the client (even in xdg-shell), by design.

Weston just implements Wayland.



Of course, if you're running XWayland (which is the case for you I guess), the X11 protocol is applied, but ultimately XWayland will disappear, it's just here to facilitate the transition to Wayland until all applications supports it.

Guest, Wednesday 25 June 2014 à 19:58 yes i was wrong cairo-dock was runnning on xwayland. But a wayland compositor can have a protocol to set windows placement it's just not implemented, wayland is not just one protocol

fabounet, Thursday 26 June 2014 à 21:11 a wayland compositor can have a protocol to set windows placement

yes but then no sane application would use it, because it would be broken on other compositors

so third party applications should stick to the core wayland protocol if they want to be able to run on all desktops, which is of course what we want

Guest, Wednesday 03 September 2014 à 20:13 Right, these mechanisms (explicit window management in particular) aren't supposed to be available to normal clients, which we see as apps. Special-purpose things like docks would get their own protocol; whether this is desktop-shell, or another protocol of your own creation, is entirely up to you. It does mean that closer integration is required with the desktop environment, but this was a conscious design choice rather than an omission.



The set_panel_position thing in particular I think is much more elegant than explicit positioning, as it avoids a horrible dance when resizing or reconfiguring monitors.

Guest, Tuesday 09 September 2014 à 03:03 Criticim is especially important now because once the protocol is frozen it will be harder to make it evolve. Don't get me wrong, I'm really excited to have a new tool like that, and I think third-party projects like us can bring a useful feedback to the Wayland developpers.



I think they already froze it with Wayland v1.0; they're going to keep adding things of course, but it's an extensible protocol, so that makes sense.



yes but then no sane application would use it, because it would be broken on other compositors

so third party applications should stick to the core wayland protocol if they want to be able to run on all desktops, which is of course what we want



Everything I've read on the subject suggests that Wayland considers use cases like Cairo-Dock's to be out of scope for the core protocol. All these kinds of use cases will require extensions to the protocol. It's up to freedesktop.org (perhaps?) to standardize something that individual compositors will implement, or perhaps a shared library will be created for those extensions, that all compositors will use.



In the reddit thread that linked to your post here, a Gnome developer chimed in and said that Gnome actually has no plans whatsoever to provide protocol extensions for third-party docks or other components that would replace part of Gnome's UI.



What will likely happen is that the Wayland ecosystem will be divided between the DEs that are complete "shells" without extensibility/configurability (Gnome, for example), and then maybe there will be other DEs that choose to make their own ad-hoc extensions, and those will be used to provide a more configurable mix-and-match experience. In a different thread, I spoke to an Xfce developer who expressed interest in Xfce becoming the "configurable DE", with a compositor that exposes Wayland protocol extensions for custom docks, etc; but obviously this person noted it was going to be a lot of work.



This might sound really bad, but when you think about it, it really isn't. Gnome has already more or less been isolating itself over the years. From the very beginning, everyone was told that while X end-user applications would keep working in Wayland, the same would not be true of DEs and window managers; no one should be surprised. This is the armageddon and rebirth of the desktop.



I'm not sure what KDE's plans are, traditionally they've been into the whole configurability stuff, and they recently modularized KDE5 to make it easy for others to use their frameworks. Maybe KDE will develop the needed extensions and standardize them at freedesktop.org for other compositors to use; who knows.

