Yashiki Tiling Window Manager

The project is organized into several specialized crates:

• yashiki/: The core window manager (WM) daemon and CLI tool.
• yashiki-ipc/: Contains the shared protocol definitions used for communication.
• yashiki-layout-tatami/: A layout engine implementing the Master-stack layout.
• yashiki-layout-byobu/: A layout engine implementing the Accordion layout.

The workspace indicator operates via a bridge pattern that connects Yashiki events to Ranma UI updates:

1. init: A startup script that launches the bridge process using reap.
2. yashiki_bridge.py: A plugin that subscribes to Yashiki events, manages the mapping of display IDs to Ranma display slots, and sends direct updates to Ranma items.

Data Flow: yashiki subscribe $\rightarrow$ yashiki_bridge.py $\rightarrow$ ranma set (direct updates)

Multi-Monitor Logic: The bridge maintains a mapping of Yashiki display IDs to Ranma display slots. When a display is clicked, the bridge executes yashiki tag-view --output <display_id> to ensure the correct display is targeted. This allows displays to be connected or disconnected without requiring a restart.

The SketchyBar menubar example uses a bridge pattern to sync Yashiki state with SketchyBar UI.

Architecture

yashiki subscribe $\rightarrow$ yashiki_bridge.py $\rightarrow$ sketchybar --set (direct updates)

Unlike minimal examples that use event triggers, this bridge directly updates SketchyBar item properties via --set commands.

Multi-Monitor Slot Assignment

The bridge maintains a slot assignment mapping Yashiki display IDs to SketchyBar display slots (1-3). This mapping is independent of SketchyBar's internal arrangement IDs, allowing displays to be connected/disconnected without restarting SketchyBar.

• On display connect: New display is assigned the lowest free slot.
• On display disconnect: Slot is freed for reuse.
• Interaction: Each slot's click handler targets the correct Yashiki display via yashiki tag-view --output <display_id>.

Unlike traditional window managers that use numbered workspaces, Yashiki uses a tag system inspired by dwm and river.

• Multiple Tags: A window can belong to multiple tags simultaneously.
• Tag Combination: You can view any combination of tags at once by toggling them on or off.
• Bitmask Representation: Tags are represented as bits in a number. This allows you to view multiple tags simultaneously by using a bitmask (e.g., viewing Tag 1 and Tag 3 together uses bitmask 5 or binary 101).

Yashiki uses a bitmask-based tag system, allowing windows to belong to multiple tags simultaneously. This is similar to the tagging systems in awesome or river.

Bitmask Mapping:

• Tag 1 = 1 (binary 001)
• Tag 2 = 2 (binary 010)
• Tag 3 = 4 (binary 100)
• Tags 1+2 = 3 (binary 011)

When writing your ~/.config/yashiki/init script, you can use shell arithmetic to generate these values:

• $((1<<0)) = 1
• $((1<<1)) = 2
• $((1<<2)) = 4

Yashiki uses a 'river-style' approach where layout engines are separate processes that communicate with the Yashiki daemon via stdin/stdout using newline-delimited JSON.

This architecture allows you to:

• Implement custom layout algorithms without modifying the core Yashiki codebase.
• Write layout engines in any programming language.
• Maintain independent state within each layout engine process.

Communication follows a request-response pattern: Yashiki sends layout requests or commands, and the engine responds with window geometries or status messages.

// Example: Yashiki requesting a layout
{"Layout":{"width":1920,"height":1080,"windows":[123,456,789]}}

// Example: Engine responding with geometries
{"Layout":{"windows":[{"id":123,"x":0,"y":0,"width":960,"height":1080}]}}

Yashiki uses external layout engines that run as separate processes and communicate via JSON. This allows for modularity and the ability to write custom engines in any language.

Common layout engines include:

• tatami: A master-stack layout where one main window is paired with a stack of other windows.
• byobu: An accordion layout where windows are stacked with a staggered effect.

Layout engines are configured via the yashiki layout-cmd command.

Yashiki does not use a static configuration file. Instead, it uses an executable configuration file located at ~/.config/yashiki/init.

• Flexibility: The init file can be any executable (shell script, Python, Ruby, compiled binary, etc.).
• Mechanism: When the daemon starts, it executes this file. The script configures the daemon by calling CLI commands like yashiki bind ....
• Application: Changes to the configuration take effect after restarting the Yashiki daemon.

#!/usr/bin/env python3
import subprocess
for i in range(1, 10):
    subprocess.run(["yashiki", "bind", f"alt-{i}", "tag-view", str(1 << (i-1))])