Rectangle is a production macOS menu-bar window-management utility that moves, resizes, and tiles application windows through keyboard shortcuts and drag-to-snap. It is not a research or data project; it is a purely native desktop application. It reads and writes window geometry via the macOS Accessibility API (AXUIElement), supporting dozens of layout actions — halves, thirds, quarters, sixths, eighths, ninths, twelfths, sixteenths, maximize, center, cascade, display transfer, and multi-window grid/row/column tiling — plus stacked-window cycling, a todo-mode sidebar, cooperative corner resize, and an optional animation engine. Architecturally, this is a Swift/Cocoa menu-bar app (LSUIElement, no dock icon, no backend). AppDelegate wires together ShortcutManager (MASShortcut bindings), WindowManager (action orchestration), SnappingManager (drag-to-snap with placement preview), MultiWindowManager (tile/cascade/stack), and a SwiftUI Settings window backed by a typed Defaults system persisted in NSUserDefaults with JSON import/export. The heart of the layout logic is a strategy pattern: a WindowCalculation protocol with roughly a hundred small calculation classes, each implementing one placement, applied through a chain of WindowMover implementations (standard, fixed-size, best-effort, edge-alignment) and optionally a display-link-driven animation pipeline with pacing, settlement, and handoff verification. The primary data flow is user input (shortcut/menu/drag) → WindowAction enum → WindowCalculation produces a target rectangle from the current screen, window, and gap state → a WindowMover writes the frame through AXUIElement with edge correction, followed by optional animation and post-move verification. Screen detection, multi-display transfer, gap math, and stack detection are separated into focused utilities. External dependencies are limited to AppKit/QuartzCore, the undocumented macOS Accessibility API, a forked-and-pinned MASShortcut, and Sparkle for auto-updates. The codebase is professionally maintained with unit tests for geometry, grid tiling, stack detection, defaults serialization, and cooperative resize, plus GitHub Actions CI that produces signed DMGs. Its main weaknesses are scale-related: a monolithic calculation factory and a ~140-value WindowAction enum with duplicated metadata, a single ~96k-token test file, and near-duplicate calculation classes for fine-grained grids. The strongest reusable assets are generic utilities (TTL cache, debounce) and pure-geometry modules that are decoupled from app state.
Apple Sharpener is a macOS system tweak that programmatically removes or customizes window corner radii, producing sharp (square) corners on application windows and optionally modifying the Dock's corner radius. It operates as an injectable dynamic library (dylib) loaded via the Ammonia injection framework and provides a CLI tool (`sharpener`) for runtime control. The architecture is a classic method swizzling tweak: the dylib hooks into `NSWindow` methods (`setFrame:display:`, `_setCornerRadius:`, `_updateCornerMask`) and the Dock's `CALayer` (`layoutSublayers`) to enforce a configurable corner radius. State is persisted via `NSUserDefaults` (in a shared suite) and communicated between processes using `notifyd` distributed notifications, allowing live changes without restarting applications. The tweak intelligently filters windows to affect only standard titled windows (excluding HUD, utility, popups, and small UI elements) and handles fullscreen mode gracefully. This is a targeted utility built for a specific use case within the macOS jailbreak/tweak ecosystem, demonstrating solid Objective-C craftsmanship and careful integration with the Cocoa framework.
plwm is an X11 dynamic tiling window manager written in Prolog. It features a modular architecture with separate Prolog modules for window management logic, layouts, menus, settings, and utilities, combined with C bindings to X11 libraries via SWI-Prolog's FFI. The system processes X11 events in a main event loop, manages window state through dynamic predicates, and provides multiple interaction methods including keyboard shortcuts, dmenu/rofi menus, and a scriptable command FIFO. Key entry points include the main Prolog file (src/plwm.pl), build system (Makefile), and installation script (tools/install.sh). External dependencies include X11 libraries (libX11, libXft, libXrandr) and SWI-Prolog.
Notion is an X11 window manager with tiling, tabbing, and floating layout capabilities. It features a modular architecture where core functionality resides in ioncore/ and extends via loadable modules (mod_tiling, mod_menu, mod_statusbar, etc.). Configuration and extensibility are driven by Lua scripts, allowing deep customization of key bindings, layouts, and status bar elements. The system handles X11 events, manages window geometry and focus, and provides session saving/restoring. Key components include a reference-counted object system (libtu/obj), Lua-C binding layer (libextl), hook system (libmainloop/hooks), and binding maps for contextual input handling. Despite its age, the codebase shows recent activity and maintains compatibility with modern X11 environments.
React Mosaic is a production-grade React tiling window manager library. It renders an immutable n-ary tree of split, tab, and leaf nodes as a fully interactive layout with drag-to-resize dividers, draggable panel rearrangement, and tab-group management. The library is the single package `react-mosaic-component`, built with TypeScript, using `react-dnd` for drag-and-drop (with HTML5 and touch backends via multi-backend), and `immutability-helper` for immutable tree updates. It supports controlled and uncontrolled usage, Blueprint theming, and React 16–19. The architecture is centered on a `MosaicNode<T>` union type, a recursive renderer (`MosaicRoot`), and a React context system (`MosaicContext`, `MosaicWindowContext`) that exposes tree manipulation actions. The core tree utility layer (`mosaicUtilities.ts`, `mosaicUpdates.ts`) is well-isolated and thoroughly unit-tested. The codebase is actively maintained, with comprehensive CI/CD (GitHub Actions for PR validation, deployment, publishing), conventional commits, and an Nx monorepo build system. Despite some legacy class component patterns in the main components, the library demonstrates strong engineering with clean type guards, immutable state handling, and extensive test coverage for edge cases. It is suitable for embedding in any application needing complex panel layouts (IDEs, dashboards, monitoring tools).
AltSnap is a native Windows desktop utility that lets users move, resize, and manage windows by holding Alt and dragging with the mouse. In production it runs as a tray application and loads a companion hooks.dll into its own process; that DLL installs low-level keyboard and mouse hooks, detects Alt+click/drag gestures, and manipulates window placement through Win32 APIs. It also implements Aero-style snapping, configurable snap layouts/zones, blacklists, global hotkeys, MDI handling, a large action system assignable to mouse buttons/titlebar clicks, and an optional elevation path. The project deliberately avoids DLL injection into other processes; instead, input is captured via WH_KEYBOARD_LL/WH_MOUSE_LL and heavy window movement is offloaded to a worker thread to keep the hooks responsive.
This repository is a comprehensive, modular dotfiles collection for a bspwm-based desktop environment on Arch Linux. It provides 18 distinct visual themes ('rices') that consistently apply color schemes, wallpapers, and style options across a wide range of applications including terminals (Alacritty, Kitty, Ghostty, ST), status bars (Polybar, Eww), launcher (Rofi), notifications (Dunst), compositor (Picom), browser (Firefox), editor (Neovim), media player (MPV), and many others. The core architecture is a modular theme application system: a central script (`Theme.sh`) sources per-theme color variables and then runs individual module scripts (e.g., `05-alacritty.sh`) that generate or overwrite application configuration files. An installer (`RiceInstaller`) sets up the entire environment, and a GUI editor (`RiceEditor`) allows runtime customization. The repository also includes numerous utility scripts for hardware detection, wallpaper selection, weather display, network management, and media control, many of which demonstrate good engineering practices like caching, parallel processing, and atomic file updates. While tightly coupled to Arch Linux and X11, the modular theming pattern and several standalone scripts are reusable in other contexts.
qtile-extras is a third-party extension library for the Qtile tiling window manager, providing a rich collection of custom widgets, layout decorations, popup toolkits, and external service integrations (e.g., Strava, Snapcast, MPRIS2, UPower). It does not run standalone; it is imported by user Qtile configuration files and adds features such as decorative borders, gradient backgrounds, global menus, status notifiers, and interactive popups. The architecture relies on lazy imports, mixin-based widget composition, and monkey-patching of Qtile internals for decoration injection. Many widgets pull data via DBus or HTTP APIs and render it through cairocffi. The codebase is well-structured with extensive tests and documentation, though certain components are experimental or personally maintained.
picom is an X11 compositor that provides desktop visual effects such as window shadows, fading, blur, rounded corners, and animations. It is a fork of Compton and serves as a lightweight compositing manager for X11 window managers. The system is built around a modular architecture with pluggable rendering backends (XRender and OpenGL), a damage-based incremental renderer, a window tree manager, and a custom animation scripting engine. Key entry points include the main session initialization in `src/picom.c`, the event loop driven by libev, and the backend initialization. Data flows begin with X11 events (e.g., window creation, property changes) processed by the event handler, which updates the window tree and triggers damage computation. The renderer then builds a list of backend commands from window layers, applies damage culling, and presents the final image via the selected backend. External dependencies include X11 libraries (xcb, xlib, xrender, xdamage, xcomposite, xpresent, xrandr), libconfig for configuration, libev for event handling, pixman for region operations, and optional OpenGL, dbus, and pcre2. The project is actively maintained with a comprehensive test suite and CI/CD pipelines.
term39 is a cross-platform terminal multiplexer and emulator built in Rust, featuring a retro MS-DOS aesthetic. It provides a full-screen text interface with window management (drag, resize, minimize, maximize, auto-tiling), terminal emulation via VTE ANSI parsing and PTY integration, session persistence through a Unix daemon, a lockscreen with OS-level authentication (PAM, macOS DS, Windows Security, PIN), and an optional Linux framebuffer backend for direct console rendering. The application supports multiple platforms including Linux, macOS, Windows, FreeBSD, NetBSD, OpenBSD, and Android/Termux, with feature-gated builds via Cargo features. The architecture is modular: an event loop drives input handling (keyboard, mouse) and rendering through a `RenderBackend` trait that abstracts terminal (crossterm) and framebuffer backends. The UI is composed of widgets (top bar, battery, network, system menu) and dialogs (config, prompt, toast, info). Terminal state is managed by `TerminalGrid` and `TerminalEmulator`, with ANSI escape sequences parsed by `AnsiHandler`. Session persistence uses a client/daemon pattern over Unix domain sockets, allowing windows to be detached and reattached. The lockscreen supports multiple authentication backends via a factory pattern. While the codebase is feature-rich and well-structured in many areas, it exhibits some technical drift: dead code artifacts (e.g., a disabled restore line in main.rs), heavy use of `#[allow(dead_code)]`, platform-specific code duplication, and unsafe operations in forking and signal handling. The rapid version history (0.1.0 to 1.6.0 in about a year) suggests fast iteration, which may have introduced some technical debt. Nonetheless, the project demonstrates strong engineering in its abstraction layers, widget system, and cross-platform support.