Cairo-Dock is a desktop interface that takes the shape of docks, desklets, panel, etc
A dock for Wayland
Cairo-Dock has now a basic Wayland
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
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).
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.
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:
Finally, launch the dock: