Update writeup.

writeup.md

@@ -4,55 +4,99 @@ Firstly, why im interested in wm's citing i3 and awsome etc as my inspiration bu
 
 ## X11
 
-Windows uses
+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.)
 
-Desktop Window Manager (DWM)
+MacOS's also have a similar situation where they build and roll out the WM along with the core operating system itself.
 
-Window management is part of the OS core
+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.
 
-Not replaceable by users, meaning i cannot make a custom one for windows systems
+The two main display server protocols to consider are:
 
+* [Wayland](https://wayland.freedesktop.org/)
+* [X11](https://www.x.org/wiki/)
 
-so i need to look into a system i can build, and as linux based operating systems are very highly customizable we can look into our options there.
+### X11 vs Wayland
 
+Wayland (created in 2012) is a much newer Display Standard as compared to X11 which has been around since 1984.
 
-The 2 options for linux on which window managers can be built are
+Although X11 has recived many updates the core philosophy remains the same.
 
-https://wayland.freedesktop.org/
+Wayland has been steadily replacing X11 across Linux distrobutions recently.
 
-and
+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.
 
-https://www.x.org/wiki/
+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).
 
-And for comparing them here are some links ->
+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.
 
-https://linux-hardware.org/?view=os_display_server
+### Decision
 
-shows wayland overtaking x11, but only very recently
+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.
 
-https://blog.davidedmundson.co.uk/blog/metrics-in-kde-are-they-useful/
+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.
 
-(shows 45% wayland and 55% x11) but a lot of older devices wouldnt switch as the difference isnt as noticeable, but for newer systems where wayland is default it was more like 80% wayland and 20% x11.
+For these reasons, I have decided to implement my window manager as an **X11 window manager**.
 
-gnome has cut off x11 support entirely while being the most used de.
+## Why use this WM specifically
 
-https://www.phoronix.com/review/x_wayland_situation
+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.
 
-This explains the problems of the x11 system
+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.
 
-https://www.linuxteck.com/x11-vs-wayland/
+It will be programmable at runtime where they can change the behaviour and add keybind based triggers too.
 
-wayland improvements for security, frame memory usage and fixing the tearing
+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.
 
-And even though wayland seems to be a more modern version X11 is time tested and has a implementation that is easier
+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.
 
-I also use X11's ssh support for remotely working with my server a lot and wayland does not have a native solution to this
+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 
 
-So I'm gonna go with an X11 WM implementation as my artifact.
 
 ##