Minutes 2026-10-15

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