Freya: Created page with " = gbRWM = Presented by Gabe pronounced “gooberwm” = What is a WM? = * Determines how windows move and resize * Tells where windows go * Draws titlebars and other decorations * The “GUI” part of the desktop environment * WMs originate from X11, WM talks to the display server to tell where windows go, compositor handles rendering ** X11 was haphazard and old, lots of long communications bogged down speed..."

2026-11-02T20:22:18Z

Created page with " = gbRWM = Presented by Gabe pronounced “gooberwm” = What is a WM? = * Determines how windows move and resize * Tells where windows go * Draws titlebars and other decorations * The “GUI” part of the desktop environment * WMs originate from X11, WM talks to the display server to tell where windows go, compositor handles rendering ** X11 was haphazard and old, lots of long communications bogged down speed..."

New page

= gbRWM =

Presented by Gabe

pronounced “gooberwm”


= What is a WM? =

* Determines how windows move and resize
* Tells where windows go
* Draws titlebars and other decorations
* The “GUI” part of the desktop environment
* WMs originate from X11, WM talks to the display server to tell where windows go, compositor handles rendering
** X11 was haphazard and old, lots of long communications bogged down speed
* On wayland, the system was flattened to make the window manager (or compositor) do ''everything''.
** Much more freedom for weirdness
** Simpler architecture
** BUT: to make a window manager you need to implement the compositor, display server, and window manager # RIVER:
* Wayland compositor that doesn’t do window management
* WM is split into a separate process
* River checks in every so often to ask where a window goes
* Much easier! Saves a lot of time!
* gbrWM is built on top of River ## Why make a WM?
* Self-defined window behavior
* It’s cool
* The gbRWM plan:
** dynamic tiling
** titlebars with tabs
** super-simple
** mouse-first design ## Demo
* Tabs correspond to windows
* Tabs can be dragged to move windows
* Keyboard and mouse both work for management
* Windows can be shrunk farther than they want to be
* Maximizable windows
* Windows can be moved to sidebar


== Internals ==

* Turns out there’s a reason most tiling WMs don’t do titlebars
* Each titlebar is a separate surface (basically a window) that needs to be rendered to and respond to user input.
** Options are software rendering, vulkan, or use an existing graphics library
** Most graphics libraries don’t work because they’re designed for a single window, chugs really hard because it sends things to the GPU one at a time
* TRICK THE COMPOSITOR INTO DRAWING FOR YOU
** Build a surface out of ''subsurfaces''
** Meant to be used to use textures of separate types on the same surface
** NOT MEANT TO BE USED FOR THIS
** Works well, even with tons of windows open
** Subsurfaces can also handle click regions for us!
** Creating/destroying subsurfaces is '''SLOW'''
*** Keep a cache of them, so we don’t need to delete and recreate them all the time!
* Text is still a challenge…
** PREMATURE OPTIMIZATION DETOUR!!
*** Store one copy of each string to display, to store fewer textures on duplicate windows
** Text is HELL to draw
** Tried Pango to draw text
*** Pango is based on glib, so zig’s translate-c feature doesn’t work with it
*** No zig pango bindings
*** but there is zig-gobject (bindings for 107 different GNOME-related libraries in a single zig dependency. includes pango!!)
*** Pango docs are full of jargon, very dense, and demos don’t exist anymore
*** Pango requires Cairo to actually draw text ## Future Plans
* Floating windows
* Window Icons
* Make the minimize button do something
* Named workspaces
* Scrollbars
* New tab button
* Searchable sidebar, not unlike the Sway scratchpad
* Need xdg-activation-support for new tabs

Minutes 2026-10-15 - Revision history