187 lines
13 KiB
Markdown
187 lines
13 KiB
Markdown
# Kutu WM
|
|
|
|
Firstly, why im interested in wm's citing i3 and awsome etc as my inspiration but the fact that using similar systems for a while now, and i wish to explore every part of the software everyone uses and doesnt even feel the existence of.
|
|
|
|
## X11
|
|
|
|
On Windows, window management is handled by the **Desktop Window Manager (DWM)** by Microsoft. Since window management is directly integrated into the operating system, it is not designed to be replaced by users with a completely custom window manager. (although extentions can be made they are not as complete.)
|
|
|
|
MacOS's also have a similar situation where they build and roll out the WM along with the core operating system itself.
|
|
|
|
Because of this, if I want to build my own window manager, Linux provides a much more suitable environment. Linux is highly customisable, and its graphical stack allows users to build alternative window management systems on top of established display server protocols.
|
|
|
|
The two main display server protocols to consider are:
|
|
|
|
* [Wayland](https://wayland.freedesktop.org/)
|
|
* [X11](https://www.x.org/wiki/)
|
|
|
|
### X11 vs Wayland
|
|
|
|
Wayland (created in 2012) is a much newer Display Standard as compared to X11 which has been around since 1984.
|
|
|
|
Although X11 has recived many updates the core philosophy remains the same.
|
|
|
|
Wayland has been steadily replacing X11 across Linux distrobutions recently.
|
|
|
|
Data from [Linux Hardware](https://linux-hardware.org/?view=os_display_server) shows Wayland's adoption increasing significantly, although this shift has happened relatively recently.
|
|
|
|
KDE's own metrics also provide an interesting picture. [David Edmundson's analysis](https://blog.davidedmundson.co.uk/blog/metrics-in-kde-are-they-useful/) showed an overall split of approximately **45% Wayland and 55% X11** at the time of the analysis. However, the distribution was quite different on newer systems, where Wayland was the default: these systems showed closer to **80% Wayland and 20% X11**. This suggests that much of X11's remaining usage comes existing installations rather than from users actively choosing it over Wayland.
|
|
|
|
There are several technical reasons for this switching. X11 has gained a lot of architectural complexity over its lifetime, while Wayland was designed to address many of these limitations specifically. Wayland provides stronger security boundaries, reduces unnecessary frame-buffer copying and memory usage, and has a more straightforward approach to compositing and preventing issues such as screen tearing. These differences are discussed further in [this comparison of X11 and Wayland](https://www.linuxteck.com/x11-vs-wayland/) and in [Phoronix's discussion of the current X11/XWayland situation](https://www.phoronix.com/review/x_wayland_situation).
|
|
|
|
Despite these advantages, X11 still has some important benefits for this project. It is a mature and extensively tested system, and its architecture and tooling are well documented. For a project where I want to focus on implementing the window manager itself rather than dealing with the underlying display protocol, this maturity makes X11 considerably more approachable.
|
|
|
|
One particularly important feature for my workflow is X11's support for remote graphical applications over **SSH through X11 forwarding**. I regularly use SSH to work with remote servers, and this provides a straightforward way of running graphical applications remotely. Wayland does not provide an equivalent native mechanism with the same workflow, meaning additional technologies would be required.
|
|
|
|
### Decision
|
|
|
|
Although Wayland is the direction in which the Linux desktop ecosystem is moving, X11 is currently a better fit for the goals of this project.
|
|
|
|
Wayland offers a more modern architecture, particularly for security, compositing, and rendering. However, X11 provides a mature and well-established environment with simpler tooling for implementing a custom window manager, while also supporting a remote workflow that I already rely on.
|
|
|
|
For these reasons, I have decided to implement my window manager as an **X11 window manager**.
|
|
|
|
## Why use this WM specifically
|
|
|
|
Given various window management systems already exist for X11 why would i try to build my own? and specifically why anyone else might want to use it.
|
|
|
|
My main focus for this project is going to be on runtime customizablity of the window manager, basically the user will have the full control on how their workflow works.
|
|
|
|
It will be programmable at runtime where they can change the behaviour and add keybind based triggers too.
|
|
|
|
This will need to be done by a runtime embedded scripting system.
|
|
|
|
### Embedded Scripting
|
|
|
|
Embedded scripting languages are programming lanaguges that are designed to be embedded in a host programming language. The embedded language is often an interpreted language while the host is a compiled static typed language. They allow adding code to the program that can be modified and interpreted at runtime. They are often used to extend on the functionality of the host language. And they also allow using functions defined in the host language which are usually much more performance optimized.
|
|
|
|
They are usually very lightweight (so that the final binary doesn't get bloated and runs fast enough). They are very useful for cuztom DSL/syntax.
|
|
|
|
We can also see a list [list](https://dbohdan.github.io/embedded-scripting-languages/) of embedded scripting languages that exist, common ones being Lua, javascript variants, squirrel, and ruby variants (mruby in particular).
|
|
|
|
These all have a C-ABI, meaning they can be used by almost any compiled language.
|
|
|
|
^ Rordrigues, C. (2023). Embedded Scripting Languages. [online] caiorss.github.io. Available at: https://caiorss.github.io/C-Cpp-Notes/embedded_scripting_languages.html [Accessed 13 May 2026].
|
|
^ Github. (2022). Embedded scripting languages. [online] Available at: https://dbohdan.github.io/embedded-scripting-languages/ [Accessed 13 May 2026].
|
|
|
|
#### What options do i have.
|
|
|
|
(https://caiorss.github.io/C-Cpp-Notes/embedded_scripting_languages.html, and mention commonality of lua etc.)
|
|
|
|
#### Why use Mruby
|
|
|
|
Why ruby is great for development for the runtime of this WM:
|
|
|
|
- Dynamic typing. it has almost no type declarations on variables, and duck typing means any object with particular behaviour can be treated the same.
|
|
- Expressive syntax. ruby has one of the most expressive syntax that improves code readability by a lot, it allows operator overloading, very clean dsl structures, minimal puntuation neccessary, and a lot of syntactic shortcuts.
|
|
- Very rich standard library. the ruby std lib has a lot of helpers for json, sockets, networking, file management, multithreading, regex etc.
|
|
- It also has a lot of inbuilt datatypes with helper methods that allow doing a lot of stuff. it has integers with no hard maximum, floating point numbers, strings and arrays, but it also has symbols, hashmaps and regex etc. for much faster development.
|
|
|
|
And as its official website itself states, ruby is easy to write, easy to read with natural syntax like spoken language.
|
|
|
|
> Ruby's expressive syntax allows you to write complex logic concisely. By leveraging powerful features like metaprogramming and blocks, you can reduce repetition and focus on solving core problems. With rich testing frameworks, you can maintain quality while achieving rapid development cycles.
|
|
|
|
> Ruby has a simple and intuitive syntax that reads like natural language. By eliminating complex symbols and verbose constructs, Ruby's design philosophy allows you to express what you want directly. With minimal boilerplate and high readability, it's friendly to beginners and maintainable for experienced developers.
|
|
|
|
For these reasons and my personal familiarity with the languge i've planned to use ruby as the languge in which the WM code is written.
|
|
More specifically we will use the `mruby` version as it allows for embedding a lightweight ruby VM into our WM that can run the scripts without needing an external interpreter.
|
|
|
|
`Mruby` is a very lightwieght impleemntation of the ruby runtime and also supports semi-compiled bytecodes.
|
|
|
|
^ Mruby.org. (2026). mruby - Lightweight Ruby. [online] Available at: https://mruby.org/ [Accessed 13 May 2026].
|
|
^ Ruby (2019). Ruby Programming Language. [online] Ruby-lang.org. Available at: https://www.ruby-lang.org/en/ [Accessed 13 May 2026].
|
|
|
|
## i3
|
|
|
|
A similar alternative to my WM is i3WM,
|
|
|
|
It follows a similar concept of customizable and tiling WM system but its configuration is static
|
|
|
|
|
|
##
|
|
|
|
then research findings for the X11 windowing system and how all teh communication etc. happens and compositors and WM's and ssh access etc. (basically the mental model behind X11's philosofy, with diagrams maybe?)
|
|
|
|
and then about DE's and what DE's that work with X11 systems exist and how they exist to make utilizing a system easier and how people take it for granted with a little secion on trying to use a a system without any WM or DE to show how hard using such systems would be.
|
|
|
|
And then focusing on WM's and how they are supposed to work with X11's event system and how much control they have over windows
|
|
|
|
then continuing that with icccm and netwm standards and their history + why standards are getting messy over time or do not apply in all cases, for example they assume WM's will always have iconic, minimized and visible states etc. (with research findings of their histories)
|
|
|
|
then explaining how a WM is not that helpful on its own so we build some basic components to make a usable system
|
|
- the components being, a simple info bar (kinda like polybar in terms of usage)
|
|
- a menu thing similar to rofi (with simple searching) but in this case reused for a clipboard manager, command runner and emoji/unicode selection thing
|
|
- and finally a notification daemon that just shows the title and body of a notification int the corner of teh screen and a little highlight in the bar
|
|
(i can easily do the whole system and i kinda have built similar stuff b4 but im more worried about teh writeup than actual project)
|
|
|
|
---
|
|
|
|
This was kinda the preface section on X11 and WM's, now we do analysis of the project i chose itself.
|
|
|
|
---
|
|
|
|
starting with what im deciding to build to actually go through this, with a section comparing xcb and the X11 library and then other x11 tools like xrandr etc.
|
|
|
|
and here about other similar systems like i3, awsome, bspwm, the suckless one, and similar for minimalism, and also gnome and xcfe and why that would be out of scope for this but how these work with X11 with
|
|
focus on the reparenting system that is standardised among these even though it is not stricly a rule needed.
|
|
|
|
and here focus on teh exact rules laid out by icccm and netwm and how much would be needed to get working and how much would be needed for full compliance which might not even be possible in certain situations
|
|
|
|
then a final concluding chart of what needs to be coded with diagrams of the system states and how they connect and teh data needed to be stored and ill be building a mostly tiling but with floating support and workspace divided system identical to i3. (basically a requirements list)
|
|
|
|
then actual implementation of the core WM with development logs of what im actually doing with screenshots errors, fixes and rewrites id have to do because of rending issues etc. (huge section here)
|
|
|
|
while using O notation to show what complexity every component has and maybe even one or 2 graphs of performance/space somparisions for teh sake of it
|
|
|
|
Then a sort of indev testing report of what works what changes i had to make to the initial requiremnts due to complexities arising etc.
|
|
|
|
---
|
|
|
|
and now for sections on each additional component
|
|
|
|
---
|
|
|
|
first the bar, research on common bars used in minimalist systems and comparisions with bars in like windows, feature wise. (also ones like polybar etc.)
|
|
|
|
and then a list of info i might need on the bar building on top of that section of what is commonly done
|
|
|
|
then a diagram of the flow of states etc. of teh code and what objects and stuff i need to do, with requirements i plan on fulfilling with the bar
|
|
|
|
then the actual implementation and logs etc. from that
|
|
|
|
---
|
|
|
|
Then i talk about abstaction and code reusablity
|
|
|
|
which i then exapnd on to talk about why i can reuse the same underlying system for command runner, clipboard and unicode selector, the fact that they all have a simple menu that can be sorted using searches and one can type a text at the top and hit enter to run it
|
|
|
|
---
|
|
|
|
then a log of building this menu and then using it to build those 3 sub systems
|
|
|
|
---
|
|
|
|
then teh notification daemon
|
|
|
|
- i first focus on research for dbus and how it works and how do i get the notification data from the apps in the first place
|
|
|
|
- then i focus on research behind existing notification systems like dunst etc.
|
|
|
|
---
|
|
|
|
tying it up together
|
|
|
|
---
|
|
|
|
here i can now show testing of the system and how it works and a little self evaluation on the implementation part of them first
|
|
|
|
and performance reports and any bugs etc. i was unable to address.
|
|
|
|
then i can show the integration of these components in a normal working situation while tying it up with the starting secion on trying to use a system without any WM, and showing how even with such a minimalistic setup we can work so much more efficiently than then
|
|
|
|
and then comparing what i built out with other ones liek xfce i3 and all in terms of how it turned out.
|
|
|
|
---
|
|
|
|
then a section on what i learnt from building this system and what i could do more and how it makes me appriciate windowing systems and parts of our computers that most people ignore while actively using
|