Window rules for floating apps, workspaces, and transparency

You want a file manager to open as a centered floating window, a chat app to appear on a chosen workspace, and only one application to become slightly transparent. Window rules can express those preferences, but only after you identify the actual windows and understand when each effect runs.

This guide uses Omarchy’s Lua helpers. Confirm that Setup → Config exposes hypr/looknfeel.lua and your main configuration loads that personal file. Older windowrulev2 or hyprlang .conf examples are not interchangeable with this syntax. Start with configuration loading if the file relationships are unfamiliar.

1. Match a window, then apply an effect

application creates a window
  → Hyprland identifies class, initial title and other properties
  → matching rules apply startup effects
  → dynamic rules respond to relevant property changes

Preference	Effect	Important condition
Float an app	float = true	Evaluate on a newly created window
Center and size it	center, size	Intended for floating windows
Open on a workspace	workspace	Startup placement, not a command moving every existing window
Follow every workspace	pin	Requires a floating window
Change opacity	opacity / transparency helper	Can combine with other opacity rules

A startup rule does not continually drag a window back after you move it. Nor does editing such a rule prove anything about a window that was already open.

2. Discover the application’s identity

Open the target app and run:

hyprctl clients

Find its entry by the visible title. A shortened teaching example:

class: org.gnome.Nautilus
title: Documents
initialClass: org.gnome.Nautilus
initialTitle: Documents
floating: 0
workspace: 1

Your output may differ. class is not necessarily the executable name or menu label. A browser web app, a Flatpak package and a native app can expose different identities. Record initialClass and initialTitle too: effects evaluated at creation use the properties available then.

An editor’s title may later become a file path, or a chat app’s title may include unread counts. Avoid title matches that depend on text appearing only after startup. Add another condition only after observing it on the window you mean to affect.

3. Make one file manager float at a useful size

If your window really reports org.gnome.Nautilus, back up your existing personal file:

cp -i ~/.config/hypr/looknfeel.lua ~/.config/hypr/looknfeel.lua.before-window-rules

Choose a fresh backup name if necessary. Through the configuration editor, add:

o.window("^org\\.gnome\\.Nautilus$", {
  float = true,
  center = true,
  size = { 800, 560 },
})

The expression matches that complete class. ^ and $ mark its boundaries; the doubled backslash in Lua makes the regular expression treat a dot literally. A broad .* would affect unrelated windows.

800 × 560 is an example in logical desktop units. Check that it fits your scaled monitor’s usable area. It may need to be smaller on a laptop; physical screen resolution alone is not enough to judge this.

Save and exit, inspect hyprctl configerrors if supported, then close the target window after saving any work and create a new one. Confirm that it floats, starts centered, and has a usable size. Resize or move it yourself: the rule is an opening preference, not a continuous constraint.

This class match can also include dialogs owned by Nautilus. Test a file dialog as well. If you only want one kind of window, inspect its startup properties and narrow the match rather than assuming all windows from the app are alike.

4. Place a chat app without stealing focus

First identify the chat window. The following assumes it actually reports discord; replace the pattern if it reports something else:

o.window("^discord$", {
  workspace = "3 silent",
})

Workspace 3 is a teaching choice. silent requests placement without switching to that workspace. Open a new chat window, switch to workspace 3 yourself, and inspect its entry in hyprctl clients. Check both placement and whether your current task kept focus.

Single-instance apps may bring an old window forward instead of creating another one. If so, a new-window placement rule has not been exercised. Save work and fully quit/reopen that app before judging the result.

On multiple monitors, workspace placement and monitor assignment are separate policies. Do not add a monitor rule until your workspace model is clear. A startup rule is not a complete docking or monitor-disconnection workflow; see display geometry.

5. Opt one app into Omarchy transparency

If you want the file manager from the earlier example to participate in Omarchy’s transparency toggle, add this separately:

o.transparent_window("^org\\.gnome\\.Nautilus$", "0.97 0.92")

The values describe active and inactive opacity. The helper also marks the window for Omarchy’s transparency controls. Nautilus already participates in the pinned defaults, so here the useful experiment is the custom values, not claiming to enable a previously unsupported app.

Check focused and unfocused text against both light and dark wallpaper areas. Multiple opacity multipliers can combine; a value of 0.97 is not necessarily the final alpha you see. App-drawn transparent surfaces and compositor opacity are different layers.

If readability worsens, remove this experimental line. Do not compensate by brightening the entire theme. For an app already covered by defaults, removal returns control to those defaults after the normal reload and, where needed, a fresh window.

6. Diagnose a rule that seems ignored

Symptom	Check
No effect anywhere	Lua syntax and whether the personal file is loaded
New windows work, old ones do not	Startup effect timing
One dialog changes unexpectedly	Match covers more windows than intended
Chat stays on its old workspace	Existing instance reused, or wrong startup class
Size differs from the example	App minimum size, scaling and other matching rules
Transparency is stronger than expected	Other opacity settings and active/inactive state

Several rules can match one window. Do not assume a new rule replaces the complete default rule set, or that every property follows one universal “last line wins” rule. Compare one changed effect at a time with a fresh window and its reported properties. Check the installed Hyprland version’s documentation before importing an old community workaround.

7. Undo and verify unaffected windows

Remove the added rules, save through the same menu editor, and reopen the target window. Startup position and size changes need another new window to compare with the original behaviour. If restoring the backup, compare it first so later edits are not silently lost.

Test the main target, another app, a dialog and both active/inactive states. A narrow rule should affect its intended window without changing the rest of your desktop. Keep a record of observed class, changed file, intended effect and how you tested it; that record helps when an app changes its identity after an update.

Sources and related guides

Omarchy window helpers · Personal appearance example · Shipped window rules · Hyprland rule reference

Continue with personal shortcuts or configuration maintenance.