Skip to content
CharlesHoskinsonPublic

About

Warlock: an Elm-based Linux window system built around immutable state and typed events. In development.

Resources

Contributing

Stars

6 stars

Watchers

0 watching

Forks

Latest commit

 

History

836 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Warlock

Warlock banner

Crafted for flow.

Warlock is an Elm desktop shell for Omarchy, bringing a Windows-style taskbar and window controls to Hyprland. It brings applications, windows, workspaces, and desktop controls together in one interface.

Try the live test drive · Visit the Warlock website

The test drive is the quickest way to try Warlock: the real compiled Elm interface on a simulated Omarchy desktop, right in your browser. Contributors build the native shell from source against matching Hyprland components, and a packaged Omarchy install is on the roadmap.

The Elm/Haskell native host is under development. The delivery ledger records 21 accepted requirements and 47 accepted scenarios out of the original 242 requirements and 417 scenarios. Each verdict retains its own tested source and scope. Persistent desktop operation and release acceptance remain open.

The menu focus component fixes focus return after dismissal, repeated Escape/reopen handling and stale Elm event handlers. Fresh clean Haskell compilation, two control suites and current Elm component regressions pass. The clean native recording and independent review accept the named ux-024 taskbar-menu focus scenario: forward and reverse traversal, Escape dismissal, reopening and return to the original eligible group. Broader popup modes and release acceptance remain open. Whole ELM-TEA-004 acceptance covers its separately tested typed frontend boundary.

The November 3 restored Omarchy attempt failed before a confirmed Warlock frame or product input. That failed attempt remains evidence; the later diagnostic menu recording does not change its result. The earlier Foot search/Refresh observation retains its older tested tuple and failures. It does not qualify the current build.

The November 3 restored run retained its expiry of November 3, 2026 at 20:02:47 UTC and its original 28-second trial deadline. Whole-EARS and current-product input/pixel hourly targets remain unmet at the recorded checkpoint. The same-user diagnostic regression exposed a missing exit observation. The corrected Haskell boundary passes the focused bootstrap, custody and JSON/redaction checks. The exit value is untrusted data; it grants no authority and does not prove cleanup or the full cross-user contract. Component and restored-trial evidence paths in STATE are machine-local references; their raw receipts have not been published or archived for public access.

The new persistent lifecycle component fixes owned-child retirement when exit races with process metadata. Focused checks pass the original owner controls, 32 generated lifecycle cases, two deterministic real-child cases and socket callback retirement. The full run passed 36 of 37 suites; its timed-out frontend/backend suite then passed a focused rerun with all 401 committed frames and the original deadlines. Persistent application and resolver wiring still need implementation and current-build Omarchy verification.

Whole TEA005 acceptance verifies the actual Elm/Haskell adapter, seven optimized Elm roots, adversarial HTTP delivery, and complete policy replay. Whole TEA002 acceptance binds pure reducer behavior to its tested source, and whole TEA001 acceptance binds the typed model contract to its own source and evidence. Native GUI, provider cleanup and release remain open.

The Warlock desktop in the test drive: taskbar across the top and Task View open over the workspace

Open an application and Warlock's portal brings it in: a ring of red ember fragments ignites, expands and resolves into the new window.

Warlock's portal opening a Browser window in the test drive: a ring of red ember fragments expands as the new window is revealed

The November 2 remote handoff includes the current beta GUI, website and tooling work, all archived engineering proposals, verification failures and stall findings. The MVP passes 639 component assertions; subscription runtime verification remains incomplete. That handoff describes an earlier stopped team. The restored-loop cutoff in that handoff is historical and grants no authorization for later runs; its component evidence does not accept native GUI behavior.

Why Warlock

Hyprland is a fast tiling compositor, and Omarchy makes it a pleasure to drive from the keyboard. Warlock adds the desktop layer around it: a taskbar that groups windows by application, a launcher, an Alt-Tab switcher, Task View across workspaces, window previews, a snap chooser, notification history, Settings, Files and a system menu. Warlock's own surfaces share one Elm interface, one design language and the same keyboard navigation, and Files opens in Omarchy's file explorer.

Window requests go to Hyprland, and Warlock shows the result Hyprland reports. When you pick a window, the taskbar marks the request as pending, Hyprland carries it out or refuses it, and the taskbar updates from what Hyprland reports.

Hyprland keeps doing what it does best: composing the desktop and managing input, focus, workspaces and window geometry.

What it does

Taskbar

A taskbar on each display keeps pinned applications and running window groups in reach. Open a group to find its windows and bring one forward.

Launcher and application search

Open Applications from the taskbar and type a name to find an installed application. The top result has an Actions button with the application's own actions and its recent files.

Window switcher

Use Alt-Tab to move through open windows. A clear highlight shows the selected window before you switch.

The Alt-Tab window switcher with window cards and the selected window marked in red

Task View and workspaces

Open Task View from the taskbar to see windows organized by workspace. Select a window or move it to another workspace using the controls beside it.

Window previews and snap layouts

Open a window group to recognize its windows by their previews, with icons when previews are unavailable. The snap chooser offers half-screen and quarter-screen positions for supported windows; Hyprland applies the resulting placement.

Notifications

Open Notifications from the taskbar to read messages and their history. Act on a live notification, dismiss it, or turn on do not disturb.

Notifications with do not disturb tiles and a live notification card with its actions

Settings

Open Settings from the taskbar to change appearance, text size, and motion. Review changes before saving them.

Warlock Settings with theme and text size choices

Files

Open Files from the taskbar to reach Home, collections, or a folder you enter. Warlock opens the location in Omarchy Files and can reuse its existing window.

Warlock Files with quick-access tiles for Home, Recent and the collections

System menu

Open System from the taskbar for volume, network, and session controls. The menu shows service state and asks for confirmation before actions such as restart, shutdown, logout, or disabling networking.

Context menus and dialogs

Open a window's context menu for actions such as moving or arranging it. Dialogs identify consequential system actions and give you a way to cancel.

Features

Checked items describe implemented interface paths; they do not certify the current Elm/Haskell native host. In the test drive, clicks, searches and settings run compiled Elm, and a simulated desktop answers in place of Hyprland and your applications.

Taskbar and applications

  • Show a taskbar on each display
  • Group running windows by application
  • Pin applications to the taskbar
  • Reorder pinned applications
  • Mark active applications and applications needing attention
  • Search installed applications as you type
  • Launch an application from search
  • Open the first search result's application actions and recent files

Windows and workspaces

  • Switch between windows with Alt-Tab
  • Select a window from its application group
  • Show windows by workspace in Task View
  • Move a window to another workspace
  • Show window previews with icon fallbacks
  • Choose a half-screen snap position
  • Choose a quarter-screen snap position
  • Open window actions from a context menu

Desktop utilities

  • Read current notifications and notification history
  • Use actions on live notifications
  • Turn on do not disturb
  • Open Home and collections in Files
  • Open an entered folder in Files
  • Adjust volume and mute
  • View networking state
  • Confirm power and session actions

Appearance and input

  • Choose the Night or Dawn theme
  • Change the shell text size
  • Adjust motion and visual effects
  • Navigate shell controls with the keyboard
  • Dismiss popups with Escape

Try the test drive

Open the live test drive in your browser. Search for an application, switch between windows, move a window in Task View, and explore the appearance settings without changing your desktop.

How it works

Architecture

Current authored production uses Elm and Haskell. Elm owns every GUI element and ordinary interaction policy. Haskell owns the local HTTP boundary, authenticated transport, backend and reviewed native integration. WebKitGTK, GTK and Hyprland are separately inventoried system libraries.

flowchart LR
  subgraph private["Private UI network"]
    main["HttpMain · Elm state and effects"]
    views["HttpBar / HttpPopup · Elm GUI"]
    owner["Haskell UI owner · role origins and admission"]
    main --> owner
    views --> owner
  end
  owner <-->|"Authenticated inherited endpoint"| backend["Haskell backend"]
  backend --> catalog["Installed application catalog"]
  backend --> pins["Durable pin store"]
  owner --> webkit["GTK / WebKitGTK system libraries"]
Loading

The controlled bridge runs real catalog and pin traffic. The earlier source-bound observation retains its bounded search/Refresh journey and failed lifecycle outcome. The current delivery state records the restored run's early UI exit before product input or pixels. Persistent desktop operation and native window controls remain unfinished. The Omarchy trial instructions retain the protected execution and cleanup requirements.

The Haskell catalog/pin store now retains uncertain acquisitions before publication and refuses to certify them as clean retirement. The component report records the real old/new regression, 36 passing production suites and bounded lifecycle models. This supports persistent ownership; it does not establish native GUI or release acceptance.

Backend result JSON now includes attempt, seven checks, failureStages, a redacted selectedOperationError and three retirement classes. These report the retained outcome without changing success criteria. A real authenticated child-exit test injects synthetic confidential stderr data; none appears in its result JSON or 32 collected ordinary logs. This verifies the selected diagnostic boundary; system credential services and other native integrations still need their original verification.

A fresh Omarchy run now retains actual cross-user bridge-credential evidence: the same selected child changes UID0 to UID1, and its next effect request is refused with ForeignUser before another policy callback. All 15 authentication cases passed with unchanged five-second conversation deadlines. The source-bound component report preserves the measured identity maps, namespace and capability change. Whole original DEL010 is independently accepted on immutable source 02b0aba0b. This accepts the authentication boundary; native GUI and release acceptance remain separate.

The original architecture-024 capability-denial scenario is independently accepted on actual bridge evidence. Whole ARC024 remains partial for navigation and resource decision integration. The ledger contains 42 accepted scenarios on their recorded source tuples; whole-requirement acceptance is 19 of 242, with all 417 scenarios preserved.

Archived host design

The following diagram and walkthrough describe the preserved prototype. Its authored C/C++ host, JavaScript adapters and Python services remain historical reference paths. Current development follows the Elm/Haskell architecture above.

flowchart TB
  subgraph L_gui["Elm interface"]
    g_main["Main controller<br/><small>Elm</small>"]
    g_bar["Bar<br/><small>Elm</small>"]
    g_popup["Popup<br/><small>Elm</small>"]
    g_previews["Preview policy worker<br/><small>Elm</small>"]
  end
  subgraph L_bridge["Browser adapters"]
    g_adapters["Browser adapters<br/><small>JavaScript</small>"]
  end
  subgraph L_host["Desktop host"]
    g_host["Native host<br/><small>C and C++, GTK</small>"]
    g_webkit_renderer["WebKitGTK renderer<br/><small>C/C++</small>"]
    g_python["Adapter daemon and<br/>notification service<br/><small>Python</small>"]
  end
  subgraph L_compositor["Hyprland"]
    g_authority_plugin["Hyprland observation authority plugin<br/><small>C++</small>"]
    g_hyprland["Hyprland on Omarchy<br/><small>Aquamarine, XWayland</small>"]
  end
  subgraph L_library["Haskell packages (standalone libraries)"]
    g_haskell["elf-observation, held-document,<br/>process-custody, protocol, runtime,<br/>native-authority<br/><small>Haskell</small>"]
  end
  subgraph L_external["Applications and desktop services"]
    g_services["Applications and<br/>desktop services"]
  end
  g_bar <-->|"Elm ports"| g_adapters
  g_main <-->|"Elm ports"| g_adapters
  g_popup <-->|"Elm ports"| g_adapters
  g_previews <-->|"JavaScript calls"| g_host
  g_adapters <-->|"script messages / evaluate JavaScript"| g_host
  g_adapters -->|"theme attributes"| g_webkit_renderer
  g_host <-->|"JSON lines over pipes"| g_python
  g_host <-->|"library calls / callbacks"| g_webkit_renderer
  g_host <-->|"Hyprland IPC"| g_authority_plugin
  g_host -->|"layer-shell surfaces"| g_hyprland
  g_python <-->|"Hyprland IPC"| g_authority_plugin
  g_python ~~~ g_hyprland
  g_hyprland -->|"Hyprland events"| g_python
  g_host <-->|"D-Bus"| g_services
  g_python <-->|"D-Bus"| g_services
  g_authority_plugin <-->|"plugin API / callbacks"| g_hyprland
  g_hyprland ~~~ g_services
  g_services -->|"Wayland and XDG"| g_hyprland
  classDef gui fill:#1a1416,stroke:#e34234,color:#f2ede4
  classDef base fill:#161112,stroke:#7a6f6a,color:#f2ede4
  class g_main,g_bar,g_popup,g_adapters,g_previews gui
  class g_host,g_webkit_renderer,g_python,g_authority_plugin,g_hyprland,g_haskell,g_services base
Loading

Explore the interactive architecture

In the archived prototype, follow one click. When you click the taskbar button of a window that is not focused, Bar checks the click against what it shows and passes it through its JavaScript adapter to the native host. The host routes it to Main, which turns it into an activation request and marks it pending. The host records the request and hands it to the Python adapter, which asks the Hyprland plugin to focus the window. The plugin focuses it inside Hyprland, checks the result and reports back along the same path. Main settles the request, and the taskbar shows the window as active once Hyprland's next window report arrives.

Elm interface. Main coordinates desktop interaction from a hidden controller document. Bar renders each display's taskbar, and Popup renders the shared menus and panels. Popup manages the window preview thumbnails, and a headless Elm worker inside the native host applies the preview policy.

Browser adapters. JavaScript connects Elm ports to browser input, native callbacks, appearance settings, and preview transport. The adapters start the Elm programs and pass messages between them and the host.

Desktop host. A shared GTK host written in C and C++ places the taskbars and popup. WebKitGTK runs compiled Elm and JavaScript and renders their HTML and CSS. A Python adapter subprocess connects the host to Hyprland and desktop services; a Python notification service receives application notifications and keeps their history.

Hyprland integration. A C++ plugin runs inside the matching Hyprland build, reports window state, handles window operations and shortcuts, and supplies captures. A C++ preview provider receives captures from the plugin and passes images through the host to the popup. Hyprland manages focus, input, workspaces, and window geometry; its C++ Aquamarine backend supplies display buffers and presentation.

Applications and services. Installed applications provide windows and desktop entries. XWayland connects X11 applications to the Wayland desktop. Omarchy Files, the audio service, NetworkManager, systemd-logind, desktop preferences, and local storage supply the services and data Warlock presents.

The archived diagram records the earlier standalone package work.

Elm

The Elm Architecture in Warlock

The Elm Architecture gives each program a Model, messages, and an update function; programs that render an interface also have a view. Every change to a program's Model goes through update. Commands and subscriptions describe communication with the outside world, and the compiler checks that every case of every message is handled.

Main coordinates desktop interaction, Bar renders the taskbar for an output, and Popup renders shared panels while managing local text input and previews. This structure gives window state and user actions a clear place to meet.

Haskell

Current authored production uses Elm and Haskell. Elm owns everything you see and touch. Haskell supervises processes, prepares the interface's verified HTML, checks binary dependencies and speaks a checked protocol with authenticated peers. The C/C++ host and Python adapter above are retained prototype designs. Strong types, explicit effects and pure functions make the current boundaries precise and testable.

Six packages in implementation/warlock/haskell provide the current library components, and the roadmap connects them into the persistent Haskell runtime the desktop runs on.

  • elf-observation parses captured GNU readelf output and resolves declared dependency graphs.
  • held-document reads identity-checked file snapshots and prepares HTML with verified content and script and style hashes.
  • process-custody runs selected tools and child-process sessions with deadlines, controlled file descriptors, and cleanup tracking.
  • protocol checks bounded bytes into a versioned envelope, records a refusal reason for rejected input, and provides a caller-owned framed socket transport.
  • runtime is a controlled bootstrap that selects a held executable, keeps custody of the process it starts, and authenticates the current session's peer before admitting a frame.

Warlock Design Language

Warlock Design Language overview

The Warlock website documents every colour, type style, shape, motion and component. The test drive applies the design language to the real Elm interface, portal transitions included.

Black and red define Warlock's primary palette. Secondary colours communicate focus, status, positive outcomes, and warnings. A focused window stays subtly distinguishable from the windows around it, and depth and shadows remain legible on near-black surfaces.

The design language gives window opening and closing a signature portal transition: a ring of red ember sparks resolves into the window. Reduced-motion and effects-off versions provide quieter alternatives. Elm sets classes and data attributes; CSS owns the visuals. The typefaces are Space Grotesk, Inter, and JetBrains Mono.

Roadmap

  • Package Warlock for installation on Omarchy
  • Provide an installation and rollback path
  • Build the Haskell backend and native runtime integration
  • Complete new-instance and window-pinning controls
  • Expand input method support
  • Extend screen reader and braille support
  • Broaden multi-display and hardware coverage
  • Complete reproducible release builds

Build and contribute

Start with the offline contributor checker. It requires Python 3.9 or newer and Git. From the repository root, run:

python3 -B plugins/warlock-contributor/scripts/warlock.py status
python3 -B plugins/warlock-contributor/scripts/warlock.py check --project-only

The frontend build instructions build Main, Bar, and Popup together. The documented build uses a compiler, package cache, and build launcher at paths on the development machine. A contributor on another machine needs equivalent inputs and a launcher. The desktop build instructions cover the native host and matching Hyprland components.

Current development now preserves window-action feedback while Applications is open, including older unresolved recovery; the narrow taskbar keeps the action-state prefix visible. See the source-bound component evidence and feedback reference. This is compiled Elm/browser component verification. Original native keyboard/AT and release acceptance remain open. New authored production is Elm/Haskell with every GUI element in Elm; the current replacement Haskell/native runtime remains under integration.

Original ARC005 authority-tuple serialization is accepted on its permitted bridge oracle, including source-bound traces and independent review. This does not qualify native mutation or the Haskell port.

The contributor checker now blocks incomplete requirement mappings before admission. Original REV005 is accepted on actual positive/negative admission evidence; this is administrative verification.

The current private GHC 9.6.7/Cabal 3.12.1.0 SDK now passes the offline production build and all 24 controlled Haskell suites (36 fixture invocations). The source-bound preparation record retains dependency revisions, plans and the initial resolver failure. That historical package tuple had a one-frame bootstrap; the bounded authenticated follow-up now supports multiple frames, while persistent desktop/native integration and original native acceptance remain open. Historical package instructions remain available for elf-observation, held-document, and process-custody.

Run the checks for the components you change using their instructions and the verification guide. See the contribution guide for the workflow.

License

Warlock is licensed under the Apache License 2.0.

Original ARC007 is now accepted on all five receipt scenarios. A valid correlated Cancelled outcome now reaches the existing cancellation state instead of remaining Pending; only its matching local reservations retire. The actual desktop-route regression passes 2,451 assertions with80 matching bridge receipts. The receipt reference separates this verified behavior from native cancellation, the Haskell protocol port and release obligations.

The current desktop application stream now connects the actual single-input/single-output Elm Main to a called Haskell catalog and durable pin backend. Applications retains all2,048 entries through explicit paging; a compact fallback keeps long names and32pins reachable under the unchanged byte limit. The retained evidence passes27Haskell suites/39invocations,8,010 actualMain/CLI checks and401complete frames in order, with real pin save/restart and malicious-input refusal. Whole original ARC003 and DEL011, including all three scenarios, are independently accepted on source 5818e78f436554a951f1b90f5c9b417e406404b6; private HTTP/WebKit, persistent UI lifecycle, native GUI/AT/IME and release remain unfinished.

About

Warlock: an Elm-based Linux window system built around immutable state and typed events. In development.

Resources

Contributing

Stars

6 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors