devlog #8 - the end is near

stardance is coming to a close, the school holidays are nearing, and I’m running out of things to add to nwwm so I think I’m going to ship it here. I’m really happy with how far I’ve come in this project and I’ve learned a ton about X11, Rust, and myself.

GAPS!!

every good modern tiling window manager has gaps, so naturally I added them to nwwm. you can configure them in the config.toml through the gaps_inner and gaps_outer rules. gaps_inner controls the gaps between the windows themselves, and gaps_outer controls the gaps between the windows and the outer edge of the screen.

other essentials

I also added the ability to move windows between two workspaces. you can now set keybinds with the movetoworkspace <workspace> action to move the currently focused window to <workspace>. this was fairly easy to implement but I did run into a bug where the wm wasn’t correctly selecting a new window to focus after the focused window was moved to another workspace. I also finally added the ability to move focus backwards instead of just forwards, which you can do with the focus last action.

promotional material

I also sunk a few hours into making a cool little website for nwwm. it’s pretty generic but it gets the job done, and has a demo, config, screenshot, project description, and an example config file. you can see the website at annaxiomm.github.io/nwwm. finally, I made a simple logo in the form of a compass (because nwwm stands for North West Window Manager )

next steps

• ship it
• cash in my loot

devlog #7 - sanity check

a bit of a short devlog here, but I decided to take a break from programming to make the repo look a bit more presentable (I’m planning to ship soon so it needs to look good for the camera!)

README changes

the existing README was quite barebones so I fully fleshed it out with a bunch of new stuff, including a proper testing tutorial, configuration help, and an entire section dedicated to what’s wrong with the project and what I’m going to fix when I decide to try and rewrite this bowl of spaghetti at some point

next steps

• cleaning up the project, writting code comments, etc
• polishing up the project with some final features, like vanity gaps
• making a landing page for the wm because I know that when it comes time to ship, most people won’t be able to try out nwwm for themselves so I want to make a little showcase (so I don’t get a bad grade for usability!)

devlog #6 - CONFIGURATION!!!

adding a config file has been in the next steps of just about every devlog i’ve made, and i finally got around to doing it!

config.toml

nwwm wouldn’t be a cliche rust project without a config.toml. but in all seriousness, i really like toml as a configuration language and it integrates really cleanly with rust anyway. so far, you can set parameters like window border, mod key, and default layout in $HOME/.config/nwwm/config.toml and nwwm will read those and apply them at runtime. unfortunately, config isn’t reloadable at the moment (next step?). you can also configure keybinds and even startup commands! i would really have liked to have lua scripting as a config but it’s just a bit too hard for a first wm project. the error handling is pretty hairy at the moment but i’ll fix that soon i promise

other stuff i’ve changed

not much else happened, but i added a feature where debug logging only happens if you run nwwm with -v or --verbose.

next steps

• better error handling in config loading
• config reloading at runtime
• better documentation (maybe a website?)

devlog #5 - self hosted?

ok it’s been quite a while since my last devlog but i’ve added a ton of new stuff - to the point where nwwm might become my main window manager soon!

docks n’ struts

“what even are those?” i hear you ask, and fear not because i am here to answer. a docked window is any kind of window that isn’t tiled, doesn’t belong to any workspace, and reserves space on the screen that other windows can’t take up. a really common example is a status bar: it persists between desktops, and reserves space on the screen. a strut is basically the space on the screen that it reserves. i implemented support for this so you can now use your favourite status bar with nwwm! i also spent like 3 hours debugging an error that happened sometimes when you closed a docked window, and ended up fixing it by complete accident

workspaces 🧰

a window manager is basically useless without workspaces, so naturally i’ve added them to nwwm. they were actually quite easy to implement since i’ve technically supported them since day 1 i just never added workspace switching. basically when you switch a workspace it checks to see if the workspace exists, then it unfocuses the current window, unmaps (hides) all the windows in the current workspace, switches to the new workspace, maps (shows) all the windows in the new workspace, and focuses the first window in the new workspace. phew, try saying that in one breath!

status bar compatibility

as i mentioned earlier, i added struts and docks so that status bars can reserve space on the screen, but i also added some ewmh hints that allow status bars to see and change the current desktop. this was really easy, i just had to add some atoms and listen for ClientMessage events, and then connect those to my existing code

next steps

• config file loading
• more ewmh 😭

devlog #12 - the end? (for now)

this is going to be my last devlog before I ship tundra, i’m really proud of how far it’s come and the fact that i’ve actually managed to finish a project for once! I didn’t quite get to add everything I wanted but most of it is there

text editor time!

i added a real simple text editor that can save and load files from the “disk”. i don’t really have anything else to say about it

rated D for dialogs

in order for the text editor to work properly, I had to make save and open dialog boxes. these are basically an unholy frankenstein of the normal dialog box and the file browser app, and they work well enough

object permanence

using JSON and the world’s jankiest serialization/deserialization system I was able to save the user’s filesystem state to localStorage so that even of you reload or close the page, your precious writing will be preserved

you’re getting the boot

real operating systems don’t open straight to the desktop - theres a whole boot sequence that leads to this (and if you’re cool and use linux it’s all on display for you). inspired by @cooki’s FPS-OS (go check it out it’s really cool) i added a boot screen that looks pretty alright I guess.

visual imagery

finally, I got around to adding icons for each app. they’re 16x16, made in aseprite over the course of about 10 minutes, and work just enough that I don’t need to redesign them constantly.

next steps

• ship it!

devlog #11 - ctrl+alt+delete

this is a bit of a shorter devlog since I basically only added one thing - a functioning shutdown sequence! first a little dialog pops up asking if you’re sure, and then the whole screen goes black and says “shutting down…”, finally followed by an elite reference (Progressbar95 players rise up!)

devlog #2 - eye (and ear) candy

i haven’t really added much for 2 hours of work - mostly just camera stuff and sounds

cool camera stuff

the camera now follows the bullet meaning you can do really cool long distance trick shots like the one in the video! i also made it so that only one bullet can be shot at a time to avoid any weird bugs. the camera follow script uses a lot of lerping to make sure it’s buttery smooth

sfx

i generated some sound effects for when you shoot, when a bullet hits a wall, and when an enemy is destroyed, in jsfxr which you can’t hear in the recording (but trust me, they sound good!)

devlog #1 - in the beninging

its been ages since i’ve tried to make a game and i’ve never actually finished one yet, so i guess lets try make one in a month!

my idea is a super simple minigolf game - except there’s just one difference: guns. that’s right, minigolf with bullets instead of golfballs! i’ve decided to name it “Rick O’Shea’s Bullet Golf” because 1) Rick O’Shea sounds like he could probably be a pro golfer, and 2) it rhymes with ricochet.

so far, i’ve added a player that looks at your cursor (who knew trigonometry would actually be useful?), which spawns bullets that fly into the direction of your cursor. the bullets can also bounce off of walls and hit enemies, and once all the enemies are dead you win.

i’m really looking forward to seeing this game through and i have a ton of ideas to implement over the next month or so

devlog #10 - new apps

after like a month-long hiatus i thought that i ought to add a few more apps - this is meant to be somewhat useful after all!

calculator

this is a really basic calculator app, basically when you press a button it adds its value (like 2 or + or .) to an expression, and when you hit the = button it evaluates the expression with eval(). yes, i know its not the safest but it works.

colo(u)r picker

this one is also really simple: every time you press a key on your keyboard, a new random colour is generated and the rgb and hex values are shown in the bottom. need i say more?

file explorer

once again, this is really basic. all it does is gets the contents of the current directory (i had to make a new fs function to return each path’s type as well) and then makes a new element for each path with an icon corresponding to what it is. there’s also a back button if you need to… well.. go back

next steps

• file opening from the file explorer
• text editor
• more functions in the calculator / better calculator

devlog #4 - +10 usability!

we’re now shifting from the realm of “experimental” to “experimental but usable”. i’ve added a ton of new features recently and i’m really happy with how nwwm is coming together.

actually good tiling

i’ve added 2 new tiling layouts: monocle, and master/stack. monocle is the easiest to understand: all windows are the same size as the screen, and the currently focused window is brought to the front. master/stack is the traditional layout you see in wms like dwm, where there is a “master” window that takes up half of the screen and the rest split vertically (or “stack”) on the other half of the screen. i also added keybinds that switch between layouts

revamped keybind system

previously, the keybind system was just using raw x11 keycodes which were really annoying because they don’t match up with any other system (25 = w??) and are keymap-dependant. so, i switched to using xkbcommon and now keybinds are defined with more human-readable keysyms like KEY_w or KEY_Return.

i also implemented a small command runner system so now you can launch commands with keybinds. so far i’ve set Mod+Enter to launch kitty and ofc these will all be configurable through the config file

mysterious bugs

i spent ages trying to debug some weird behaviour where bound keys wouldn’t register as keypresses if no windows had been opened in nwwm yet. after a lot of trial and error, and a few ChatGPT therapy sessions, i discovered that my error was one letter: i had keyboard_mode in the global mouse grab (which i need for click to focus) set to GrabMode::Sync instead of GrabMode::Async (fml)

next steps

• more usability (moving windows, closing windows)
• better EWMH compliance
• support for temporary and permanent floating windows (i.e. tiled windows that you make float, and windows that only float like rofi)
• config file when?

devlog #3 - wow! visuals!

how many times can i call conn.send_request() in one program??

config file

i made a struct called Config which the wm owns, and it has values like border width, color, and keybinds. eventually it will read from a config.toml file but for now it’s all hard coded in the source code.

window borders

windows now have borders with color and width deriving from the Config (meaning they’ll be configurable through a config file at some point!). also, the currently focused window has a different border color (also configurable!)

modular keybinds

instead of hard-coding keybinds, i gave Config a child called Keybinds, which are hard coded in the source code… but eventually they’ll be part of the config file. when each keybind is called, it calls an Action which is linked to a function call in the wm. later there’ll be plenty of actions for anything you can think of, but for now theres only FocusNext which… focuses the next window!

next steps

• config.toml loading
• better tiling (again)
• gaps
• EWMH compliance

devlog #2 - an actual window manager

x11 is an ancient beast, full of mismatched types (screen height is a u16, window height is a u32, window position is an i32, etc), difficult protocols, and more double colons than you can shake a stick at, but i’m working through it.

a (tiling) window manager

i started off by storing a list of open workspaces in the main wm struct, and each workspace has a list of open windows (and a tiling layout). then, i made the wm listen for DestroyNotify events and remove them from their respective workspaces. soon after marvelling at my creation i realised that i could only see one window at a time, so i worked on implementing a basic tiling algorithm. so far, all i have is columns (window_width = screen_width / num_of_windows) but i’m working on adding master-stack tiling (what dwm uses)

focus!

i also realised that it’s no use having multiple windows if you can only use type on one, so i made each window grab the left click, and then listen for ButtonPress events, focusing the clicked window.

next steps

• more tiling layouts
• cosmetic stuff (borders, gaps)
• keyboard shortcuts

devlog #9 - files!

what’s an operating system if you can’t have files? so, i decided to write a basic filesystem for tundra. paired with a simple terminal and now tundra is actually kind of cool!

the filesystem

tundra uses a really simple filesystem model: there’s a File and a Directory class that both inherit from FSNode, Files have names and contents and Directories have names and children. tundra uses a traditional unix file layout (/home, /bin, /etc and so on) because its cool.

the terminal

i really wanted some way to navigate the filesystem but didn’t feel like implementing an entire file browser so I added a simple terminal. it has a few methods like writeln and readline which you can use. all the commands (including the shell!) are defined in their own classes, just like apps, which makes it really easy to add new ones. so far, i’ve added cd, ls, mkdir, touch, cat, and my own version of neofetch.

next steps

• an actual file browser
• some more commands
• ANSI escape codes for colours
• a text editor to make files for the filesystem

devlog #1 - getting things started

after working on tundra I decided that I wanted to make a window manager for an actual os instead, so I loaded arch onto an old macbook and got started.

xlib woes

I initially started by loosely following a tutorial that uses xlib for rust, but I soon realised that any direct mapping to C from rust is going to be an absolute horror to use (literally every function call had to be unsafe), so I switched to xcb. it has a slightly different API but it’s cleaner and i3 uses it so it must be good.

current features:

• it runs
• it doesn’t crash
• you can open a window (by externally injecting it from a command prompt

next steps:

• storing open windows in a struct / list
• basic tiling

devlog #8 - too many changes!

my devlogs from here on are going to be getting a lot longer now because i’m really settling into the grind, so i’m going to try out a more structured format.

dialogs!

i implemented a whole dialog box system into caribou (the window manager). so far it only has confirm (cancel/ok) style dialogs but it’s modular so i’ll be sure to add plenty more in the future. dialogs return promises that resolve with a value when an action happens (like when the dialog is closed), and this can then be used to execute code. this all came about because i wanted to add fullscreen mode but apparently browsers don’t like it when you request fullscreen without user interaction so here we are!

changelog changes (?)

the changelog, as promised, pulls directly from github to ensure you always get the most up-to-date changes with minimal effort on my end ! it uses marked and DOMPurify to parse the CHANGELOG.md from the repo and to make sure you are personally secure from anyone who’s dumb enough to waste their time trying to attack tundra.

preparing for themes

soon, i’ll work on adding themes to tundra so i decided i’d make it a bit easier for myself by making every single value that might want to be changed in css a variable. this was excruciatingly painful but we got through it in the end (it took like 10 minutes max). also, the background is now loaded dynamically through js which will lead to custom backgrounds at some point (much to the dismay of my browser’s performance)

next steps

• improve the dialog system and add more dialog types
• add a filesystem (very scary)
• add more apps
• add theming and changeable backgrounds

devlog #7 - now we’re getting somewhere!

tundra is starting to take off! i’ve changed the look of the taskbar very slightly (there’s now more padding), and i’ve also revamped the appdrawer so that it looks cleaner (and more like SerenityOS). also, submenus! now the appdrawer can be more organised as I continue to add apps instead of turning into a wastebin of buttons.

i deleted all of the original apps and have replaced them with (so far) an updated welcome/about (with wally, the derpy walrus who’s tundra’s new mascot), a proper changelog (eventually i’ll make it pull from github but for now it’s hardcoded), and a cube to test out threejs.

devlog #6 - more taskbar stuff

i decided that it’s probably a good idea to be able to see what apps you have open, so i implemented a little window list in the status bar. it’s pretty rudimentary - it just makes an element for each open window and updates any time a window is added or removed. eventually i’ll get around to adding window logos and context menus that let you close and minimise windows from the taskbar but that’s a bit advanced for the minute.

devlog #5 - visual updates

i decided i wanted to make tundra look a bit like serenityOS, so i modified the window header to include the distinctive red gradient. i also added a proper focusing system which required a decent rewrite of a portion of caribou (the wm).

also, i worked on centralising the wm. previously, windows handled their own focusing and closing but since i’ve discovered customevents windows now request this behaviour from the wm. finally, windows now auto-focus when you open them!