<20.11.14.19.08> deskwm: baby's first wayland compositor, update #1
█ █
█ █
████ ████ ████ █ █ █ █ █████
█ █ █ █ █ █ █ █ █ █ █ █
█ █ ████ ████ ███ █ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █
████ ████ ████ █ █ █████ █ █
In my last post here I said "Creating a window manager in X might be more quick
and doable" and I've changed my mind now that I've actually started to put
together a wayland compositor. I've been diving deep into both swc* and
wlroots**, libraries that abstract away the more boilerplatey boring stuff from
implementing a wayland server or client, allowing you to focus on implementing
the more fun side of whatever you're building. Of course, reading these has
been incredibly interesting too, but there is no need to re-implement what they
provide when creating my own compositor, so I've opted to use one. Although I
do read how swc has implemented some things, in case I prefer their approach
for a given functionality, I have used wlroots for the base of much of the
code in my compositor.
So getting to it: I created a wayland compositor!
As might be suggested by the big text above, its name is deskwm, following the
arguably over-done but IMO usefully informative culture of naming X11 window
managers "<something>wm". deskwm (code @
https://mcol.xyz/code/deskwm) follows
closely the ideas I put forward in my previous phlog post.
The central paradigm of deskwm is that there is a 'desk', or a small number of
desks. A desk -- as you well know from, you know, desks -- is a large surface
on which you have all your work spread out and positioned arbitrarily in a way
that seems intuitive based on how you want to organise your things and your
thoughts. Unlike real desks, these desks have no limit to their width and
height. This breaks away from the conventional idea of a workspace, where you
have your rectangular space with the same dimensions as your output in which to
place your windows. (A WM that comes close to this idea is paperwm***, which
scrolls sideways to show more windows.) As of yet, spawned windows are allowed
to take their requested geometry and need to be positioned by the user with the
cursor. I may implement some kind of light tiling just to limit unnecessary
overlaps, as you might find in the more 'mainstream' WMs like Kwin.
Some things that I have implemented so far:
- A configuration file reader, which only interprets like 3 options.
Keybindings are not one of these, so all key bindings are currently
hard-coded.
- Super simple desk panning: hold the mod key, and moving the mouse will pan
the view.
- Super simple desk zooming: mod + scroll up/down will zoom in/out the desk
view. Imagine zooming in and out of something like inkscape, where the
windows get smaller as you zoom out and you can see them all, or you can
zoom in and magnify a single window if you really feel like it.
- Tiled wallpaper. This is needed due to the desk panning, so the wallpaper
repeats itself as you pan the desk. This lends itself beautifully to
wallpaper designs made for repeated patterns, as discussed on the forum****.
- A reset to undo any panning and zooming. This will soon evolve into a
vi-style 'marking' system, where you do "mod-m then <key>" to save your
current view's desk, position, and maybe zoom. This will form a key part of
the navigation.
There are many, many more things I need to do to get it to a real usable state,
but these I am tracking in the readme's to-do list.
All in all, I'm very impressed with the relative simplicity and intuitiveness
of wayland and its protocols. Or, perhaps, I should give more credit to
wlroots' implementation, as this is primarily what I've been basing this all
on.
*
https://github.com/michaelforney/swc
**
https://github.com/swaywm/wlroots
***
https://github.com/paperwm/PaperWM
****
https://nixers.net/Thread-Tiling-Wallpapers
[Sat Nov 14 20:08:40 2020] -- powered by smtpd(1)
