Window Rules PRO

Like Named Workspaces, this pane is a two-column editor: the rule list (＋ / －, context-menu delete, ▲ / ▼ ordering in the detail header) and the rule editor with three blocks: name, Match, and Action. Rules are evaluated by score: each matching criterion is 1 point, and the highest-scoring rule wins. That lets a broad app-level rule coexist with a specific title-level one.

The rule editor

Rule name

An optional label shown in the list; unnamed rules display their match pattern.

Match

Two regex fields, App ID (bundle identifier) and Title (window title), each with two helpers:

• Pick App / Pick Title: dropdowns of your currently running apps (Name: bundleID) and open window titles. One click fills the field.
• Regex Helper ( </> ): a sheet with preset patterns (exact match, contains, starts-with…) and a live test box that tries your pattern against the running apps as you type. A lint hint also warns about catastrophic-backtracking risk in appId patterns. See below for the full sheet.

A third control, Window type, is a segmented picker that filters the rule by FazerWM's float classification:

Action

The Regex Helper

Clicking the </> button beside App ID or Title opens a sheet that builds and tests the pattern for you:

The sheet has two halves:

• Live Test: type a pattern and it is tested against your running apps (App ID mode) or open windows (Title mode) after a 200 ms debounce. Matching rows are tinted green with a ✔, the counter shows Results: N/M matches, and the ↻ button re-scans the app list. In Title mode a Custom field lets you test free text instead of live windows.
• Patterns: a segmented category picker (App ID Patterns or Title Patterns, plus General Syntax), a search field, and preset cards showing the name, the pattern, a description, and examples.

Clicking a preset card applies it. Many presets are generative: they derive the pattern from what you already typed. Prefix Match (Developer) extracts the developer prefix from a bundle ID, and Contains extracts the searchable term. Some presets also offer a word or position picker to insert at the start, the end, or an exact spot in your pattern.

Rule structure in YAML

windowRules:
  - name: Picture in Picture      # optional label
    match:
      appId: regex pattern        # match bundle identifier
      title: regex pattern        # match window title
      floating: false             # optional: tiled windows only
    floating:                     # any subset of:
      enabled: true
      avoidMouse: true
      sticky: true
      position: { x: 0%, y: 100% }
    width: 50%                    # fraction | Nx | Npt
    workspace: chat               # name | number | current
    group:
      name: terminals
      mode: tabbed

Match criteria

  - match:
      appId: com.blackmagic-design.DaVinciResolve
      floating: false
    width: 100%
    workspace: 2

Scoring

Each matching criterion scores 1 point; the highest-scoring rule wins. Broad and specific rules can coexist:

windowRules:
  # Broad: matches any Firefox window (score: 1)
  - match:
      appId: firefox$
    width: 50%

  # Specific: matches Firefox PiP only (score: 2)
  - match:
      appId: firefox$
      title: ^Picture-in-Picture$
    floating: true
    position: center
    width: 40%

Floating windows

Floating windows are left out of the tiling layout: they keep their own size and position and stack like ordinary macOS windows (there is no separate "floating layer"). A window floats either because the source app already defines it as floating (dialogs, accessory apps, elevated windows; automatic and free), or because a window rule floats it explicitly.

The full model, including window states, the Hyper+Z before/after view, and how floating relates to tiling, is covered in Core Concepts: Scrollable Column Tiling → Floating Windows.

• Avoid mouse keeps the window away from the cursor (see the table above).
• Sticky windows stay visible across workspace switches.
• Position pins them to a preset or exact coordinates.

Auto-Float (built-in, free)

FazerWM floats certain windows automatically, with no rule, so dialogs and utilities behave naturally:

• Dialog and modal windows: detected by the accessibility subrole (AXDialog or AXSystemDialog)
• Menu-bar (accessory) app windows: apps like 1Password, Alfred, and LuLu running the .accessory policy
• Elevated-level windows: windows the app places above the normal macOS window level

Workspace renames

When you rename a named workspace in the Named Workspaces pane, window rules that target it by name are rewritten automatically, so you never have to fix rules after a rename.

Examples

windowRules:
  # Terminal with fixed width
  - match:
      appId: ^org\.wezfurlong\.wezterm$
    width: 80%

  # Firefox PiP as floating, away from the mouse
  - match:
      appId: firefox$
      title: ^Picture-in-Picture$
    floating:
      enabled: true
      avoidMouse: true
      sticky: true
      position: { x: 0%, y: 100% }
    width: 50%

  # Float a specific app window (shorthand)
  - match:
      appId: ^com\.apple\.finder$
      title: ^Copy$
    floating: true

  # Float with exact position
  - match:
      title: ^StatusBarServer$
    floating:
      enabled: true
      avoidMouse: true
      position:
        x: 10%
        y: 90%

  # Comms apps grouped in one tabbed column
  - match:
      appId: ^(com\.apple\.mail|com\.ferdium\.ferdium-app)$
    group:
      name: comms
      mode: tabbed

  # IDE on workspace 2, wide, preferred display
  - match:
      appId: ^com\.jetbrains\.intellij$
    workspace:
      name: 2
      preferredDisplay: [LG Ultrawide]
    width: 80%