Choose a window layout for the task: tiling, scrolling, groups and scratchpad

You are editing a page, reading its documentation and watching a terminal. Opening a fourth window makes everything too narrow. Should you resize, switch layout, group windows, or move one to a scratchpad? Each choice changes a different part of the workflow.

This guide follows the pinned 4.0.0.alpha source. Confirm your bindings with omarchy menu keybindings --print. In this snapshot Super + L cycles dwindle → scrolling → floating, rather than simply switching between two tiled layouts. Older releases and personal shortcuts can differ. The diagrams below are conceptual arrangements, not screenshots or guaranteed placement.

1. Separate layout, grouping and workspace

monitor displays a workspace
  → workspace layout allocates space to tiled windows
  → a group shares one allocation between several windows
  → a floating window sits outside the tiling arrangement
scratchpad is a separate special workspace shown over the current one

Choice	Main benefit	Cost to consider
Dwindle tiling	See several task surfaces together	New tiles divide available space
Scrolling	Keep useful window widths on a horizontal strip	Some windows are outside the visible viewport
Floating workspace	Place overlapping windows yourself	You must manage overlap and focus
Group	Alternate apps inside one allocation	Only the selected group member is visible
Scratchpad	Briefly access a tool without leaving the main task	Hidden tool is easy to forget

Groups and scratchpad are not additional values for general.layout. Nor is making one window float the same as switching the whole workspace into floating mode.

2. Prepare one safe task workspace

Use an ordinary positive-numbered workspace with no unsaved experiment files. Keep an editor, browser and terminal open, preferably using test content. Record the workspace and both layout choices:

hyprctl activeworkspace
omarchy-hyprland-workspace-layout-current
omarchy-hyprland-workspace-layout-default

The first layout command reads the active workspace; the second reports the default for workspaces without a saved choice. They may legitimately disagree. Record whether that workspace already has a saved override under ${XDG_STATE_HOME:-$HOME/.local/state}/omarchy/workspace-layouts/. Back up an existing file for the recorded numeric ID before experimentation, using a new backup name outside that directory.

Keep a simple task: read a browser paragraph, change a line in the editor, then inspect terminal output. Compare how much switching and resizing each arrangement requires. Do not judge only how many windows fit in a photograph.

3. Dwindle: prioritize simultaneous visibility

Cycle to dwindle and verify with the current-layout command. Open the three apps, then focus with Super + Arrow. Super + J changes the active split; Super + Shift + Arrow swaps windows. Check the installed keybinding descriptions before using them.

+-------------------+-------------------+
| editor            | browser           |
|                   +-------------------+
|                   | terminal          |
+-------------------+-------------------+

This is a possible arrangement, not a prediction of launch order. Focus affects where a new window is inserted; the existing split tree also matters. If the terminal is already floating, it is not another tile until you deliberately toggle it with Super + T.

Try adding a fourth test window. If the browser’s paragraph becomes awkwardly narrow, first ask whether it must be visible simultaneously. Moving occasional tools away may be better than continually shrinking everything.

An unusually narrow single-window view can also come from Omarchy’s single-window square-aspect preference. That is separate from the layout. Check the appearance menu before assuming the monitor or dwindle is broken.

4. Scrolling: prioritize usable widths

On the same workspace, cycle until the current-layout query says scrolling. Move focus left/right and watch the viewport follow windows beyond the display edge.

horizontal strip: [editor] [browser] [terminal] [extra tool]
visible portion:          [browser] [terminal]

The hidden editor still exists. Scrolling the desktop is different from scrolling a web page: use compositor focus controls, not an application’s wheel gesture, to test this distinction.

The pinned default column width is 0.49, aimed around two columns. If you want a reading workspace dominated by one column, back up your personal looknfeel.lua and try only:

hl.config({ scrolling = { column_width = 0.97 } })

This sets a default width, not a command that promises to resize every existing column to exactly 97%. Gaps, single-column behaviour and existing resized columns also matter. Apply through the menu and test a new window. Compare two-column cross-reference against one-column reading, then remove the experimental line if two-column work is faster. Personal example · Hyprland scrolling options

5. Floating: prioritize placement and overlap

Cycle once more and verify floating. Move and resize with Super + left/right mouse drag. In this snapshot Omarchy implements the mode by tracking window tags; it is not a native Hyprland tiled layout named floating.

Mode-created floating windows get integration for titlebars, shadows and opacity. The titlebar plugin must be available for its controls to appear. A missing titlebar does not by itself mean the windows failed to float. Do not install an unrelated old plugin as the first fix. Workspace mode implementation

This is useful for tools needing irregular sizes. It is less helpful if you repeatedly hide the terminal beneath the browser. Compare Alt + Tab and explicit placement, then return to tiling. Windows floated by the mode are returned to tiles; windows already floating independently are preserved. Consequently, a dialog may remain floating after the workspace returns to dwindle.

Floating workspaces can require opaque windows for readability. If your transparency experiment appears ignored here, compare on a tiled workspace before modifying opacity rules.

6. Group alternatives; put brief tools in the scratchpad

Group two windows you rarely need side by side

Focus a browser test window and press Super + G. Open another disposable browser window while that group is active. The new window joins the group in the documented workflow. Use Super + Ctrl + Left/Right or Super + Alt + Tab to switch members.

one allocation: [docs browser | reference browser]
                 selected member is visible
other allocation: editor

If you must compare both pages continuously, a group is the wrong choice. Pull the selected member out with Super + Alt + G, or dissolve the group with Super + G. Distinguish a group member from a browser tab: the compositor groups windows, while the browser owns tabs inside its window. Observe the group bar and selected title, not just the number of running browser processes.

Keep an occasional terminal available without allocating a permanent tile

Focus a disposable terminal and press Super + Alt + S to move it to special:scratchpad without following it. The disappearance is expected. Press Super + S to show it over the current workspace; press again to hide it.

A hidden scratchpad terminal is still running. Hiding it does not stop a build, pause a timer or save shell state against a logout. Before leaving a long task unattended, read lock and awake behaviour.

To return the focused terminal to an ordinary workspace, use Super + Shift + 1 only if workspace 1 is your intended destination. This moves the window and follows it. The pinned default hides the special workspace when changing ordinary workspaces; a disappearing overlay does not prove the tool closed. Bindings

7. Understand which choices persist

The layout toggle stores positive-numbered workspace modes under workspace-layouts/<id>.lua. The default command stores default.lua in that directory. Saved choices are loaded during configuration, separately from your looknfeel.lua.

omarchy-hyprland-workspace-layout-default scrolling

Use this only when you want a persistent default change, after recording the original. Explicit workspace choices keep their own mode. Cycling a workspace onto the current default removes its separate saved override, so it follows later default changes. Changing general.layout alone may appear ineffective when a saved default is loaded later. Default command · Toggle persistence

Do not expect grouping or scratchpad contents to survive logout as a restored application session. Saved layout is not saved app state. The toggle also does not provide the same mode management for named negative-ID or special workspaces.

8. Find missing windows and undo the experiment

Situation	Evidence and recovery
A window is beyond the edge	hyprctl clients; focus along the scrolling strip
A window has vanished after grouping	Select another member or move it out of the group
A terminal vanished after the scratchpad move	Show the scratchpad and move it to the intended workspace
One window remains floating after a mode change	It may have floated independently; inspect before toggling it
Default changed but one workspace did not	Its saved per-workspace mode remains
Windows are on another monitor	Inspect workspaces and follow multi-monitor planning

Return the terminal from the scratchpad, dissolve the test group and restore the recorded workspace mode. Remove your experimental column-width line. If the workspace originally followed the default, cycle to that default and confirm its separate saved file is gone. If it originally had an explicit override, compare and restore the backed-up file, then reload; merely matching the old visible layout may not restore the old inheritance policy.

Similarly, if you changed the default, restore its previous value; if no default.lua existed before, archive only the newly created file outside the loaded directory and reload rather than inventing a previous saved setting. Never remove the entire state directory to reset one experiment.

Finally run the original reading/editing/output task again. Keep a layout because it reduces friction in that task, not because it is the newest option. Continue with window rules and appearance comparisons. These workflows are source-reviewed, not hardware-tested.