Hi folks
Mir’s work to implement Wayland support is going well! The basics are in place: clients can connect, create windows and draw into them, and mouse, keyboard and touch inputs work. We’re building our Wayland Conformance Suite wlcs to ensure Mir is behaviour equivalent to other Wayland implementations.
Of course there’s many more features to implement before we have full Wayland support: copy/paste, drag & drop, more window management functionality, sub-compositor and sub-surface support. There are all the protocol extensions in the Wayland-protocols repository to deal with too. We’ve got plenty to do!
However we’re also at the place where we need to reach out to the community and ask what are the aspects of your desktop that you value most, to help us figure out a direction for Mir. Below there’s a couple of topics, please have a read, and if you’ve got any thoughts on those topics, do reply. All feedback welcome!
1. Desktop architecture
Super simply speaking, a desktop environment consists of a server/compositor/window manager to show apps windows, together with panels, docks and desktop to allow users launch those apps and switch between app windows.
There is a spectrum of ways to architect this, but here are the extrema:
Monolithic desktop
This is where server/compositor/window manager and panels/docks/desktop are all in a single process.
Pros:
- ease of implementation: no IPC needed to sync state
- security - impossible for apps to learn about or manipulate shell in unexpected ways
Cons:
- non-modular, cannot mix & match third-party panels/docks.
- less robust: a line of code in the dock can cause the entire shell to crash, losing the user’s session.
- less efficient: rendering pipeline more complex, and more susceptible to framedrops.
This is largely how Gnome Shell’s Wayland support is implemented.
Highly-modular desktop
Here the server, compositor, window manager and each panel/dock/desktop are all individual processes
Pros:
- can easily mix & match third-party panels/docks to build a shell that works for you.
- more robust: separate processes means a crash in any component (except the server) is recoverable, meaning User less likely to lose session.
- more efficient: rendering is simpler, so compositing is more efficient and less likely to drop frames.
Cons:
- complex to implement, rely on IPC to sync state between separate processes (risking race conditions - what if server destroys a window just as compositor starts to draw it - needs extreme care to avoid)
- security is compromised: e.g. the APIs screenshot utils or hotkey listeners use can be used maliciously by a bad app.
This is how X11-based desktops work today.
I think we all can agree we would like all of the Pros, and none of the Cons, but is that even possible? Can you suggest a design that gives the best user experience, yet doesn’t leave the developer with a complex job?
To throw my idea in the mix, I like this approach:
Server/Compositor/Window Manager is a single process. Panels/Docks/Desktop are all separate processes, but have privileged access to Wayland extension(s) to give them special APIs so they can control the window stack, position themselves on screen, etc.
I think this design would solve most issues. There are ways to implement privileged clients with Wayland already (Weston does it), but this approach carries threat of adding yet more extension(s) to the Wayland ecosystem. I don’t want Docks/Panels that only support Mir’s Wayland, they should work on all, but how to do that…
2. Desktop customisation/theming
How much UI flexibility would you like for your desktop? Do you yearn for wobbly windows and fire effects, and mourn the desktop cube? Or are you more contented with a more 2D desktop, with custom animations for window manipulations like open/close/minimize/maximise? Or is a tiling window manager more your thing?
Mir server was designed to be modular and easily integrated with other toolkits. The current built-in Mir compositor is super-basic, it draws 2d windows with no fancy effects, but it could use hardware compositing APIs on Android for low-latency and power efficient graphics. Also Mir’s window manager exposes multiple hooks to let you impose whatever WM strategy you’d like.
We want to know what kind of graphics capabilities you’d like your desktop to have. Is there an existing graphics toolkit that you think would provide all the pizazz you need? Should tiling be a built-in option?
For “prior art” consider Unity8. This was built on QtMir (similar to QtWayland server), a library on top of the Mir server library that replaced the default Mir compositor with the Qt scenegraph renderer, so we could build the whole desktop (including panels/docks) in QML. We lost access to some acceleration techniques though that raised latency (but I had ideas how to restore that!).
3. Most Requested Features
What are the aspects of your desktop you most value? Are you a gamer? If so, I bet you care about low-latency graphics and hotkey support. Do you watch lots of video? Then screen-tearing needs to be eradicated. Have you a laptop with multiple GPUs and need it to intelligently switch GPUs? But what else is important to you?
We’d love to hear what you have to say, as it’ll help us decide our future direction. Please, don’t be shy!
Thanks
-G
