Per-workspace or Per-monitor Layout Configuration (Scrolling Layout)

[rivera-diego]

Currently, Hyprland allows some layout configuration via layoutopt and windowrule. However, there is no flexible way to define layout behavior per monitor or per workspace, which is especially useful in mixed-orientation setups.

This feature would allow configuring properties like column_width, direction, and other layout options depending on the active monitor or workspace.

---

In multi-monitor setups, especially with:

• A horizontal primary monitor

• A vertical secondary monitor

…layout needs differ significantly.

Examples:

• Horizontal monitor → column_width = 0.5

• Vertical monitor → column_width = 0.3–0.4

Current limitations:

• layoutopt is limited in scope

• windowrule is too granular and lacks context awareness

• No clean, declarative way to define layout per monitor/workspace

---

Current Limitations

1. Limited workspace configuration

workspace = 2, monitor:HDMI-A-1, persistent:true, layoutopt:direction:down

✔ Supports direction
❌ Does not allow full layout control (e.g. consistent column_width)

---

2. windowrule is not enough

windowrule {
  name = vscode_starting_width
  match:class = code
  scrolling_width = 1.0
}

✔ Works per application
❌ No monitor/workspace context
❌ Not scalable for complex setups

---

Proposed Solution

✅ 1. Per-monitor configuration

monitor = DP-1 {
    layout = scrolling
    column_width = 0.5
    direction = right
}
monitor = HDMI-A-1 {

layout = scrolling

column_width = 0.33

direction = down

}

---

✅ 2. Per-workspace configuration

workspace = 2, monitor:HDMI-A-1, persistent:true {

layout:scrolling {

column_width = 0.33

direction = down

}

}

---

✅ 3. Optional contextual rules

layout_rule {

monitor = HDMI-A-1

workspace = 3

column_width = 0.4

}

---

Benefits

• Better use of space on vertical monitors

• More declarative and clean configuration

• Reduced reliance on windowrule

• Scales well for advanced multi-monitor setups

---

Real-world Example

Setup:

• DP-1 → horizontal main monitor

• HDMI-A-1 → vertical monitor

Desired behavior:

Monitor	Direction	Column Width
DP-1	right	0.5
HDMI-A-1	down	0.33

---

Alternatives Considered

• windowrule only → too granular

• layoutopt only → too limited

• External scripts → not elegant

---

📎 Additional Notes

This would be especially useful for:

• Scrolling layouts

• Mixed vertical/horizontal setups

• Developer workflows (VSCode, browsers, terminals)

---

Closing

Adding per-monitor and per-workspace layout configuration would significantly improve flexibility and usability in Hyprland, especially for advanced users with custom setups.

[sebsassi]

I second that this is crucial for multi-monitor setups with mixed aspect ratios. I currently use a horizontal and a vertical monitor with horizontal and vertical scrolling layouts with 1/2 and 1/3 column widths, respectively. But I have to manually adjust every, single, window I put on the vertical monitor, which gets a bit annoying.

It is also natural that since we already have per workspace layouts, and some control over layout options per workspace via layoutopt, all layout options should be available per workspace.

The existing layoutopt syntax can handle some of the options, but things like the explicit_column_widths list would be extremely awkward. I think this requires a new workspace rule syntax in line with the new windowrule and monitorv2 syntax. My gut reaction would be something like

workspacev2 {
    name = 1
    monitor = DP-1
    ...
    layout = scrolling
    layoutopt {
        column_width = 0.5
        follow_focus = false
    }
}

The same layout and layoutopt could be available in monitorv2. And naturally, if a workspace does not define a layout or a layout option, we look if the monitor does, and if it doesn't, we use the global one.

[soothsayerr7]

I also have a horizontal + vertical setup and found the following to work well for myself as a provisory solution.

hl.monitor({
  output = 'DP-1',
  mode = '2560x1440@164.96',
  position = '1440x920',
  scale = 1,
})

hl.monitor({
  output = 'DP-2',
  mode = '2560x1440@164.96',
  position = '0x0',
  scale = 1,
  transform = 1,
})

local wr = hl.workspace_rule

for i = 1, 9 do
  local wsh = tostring(i)
  local wsv = tostring(i + 10)

  wr({ workspace = wsh, default_name = 'H' .. tostring(i), monitor = 'DP-1', default = (i == 1) })
  wr({ workspace = wsv, default_name = 'V' .. tostring(i), monitor = 'DP-2', default = (i == 1) })
end

wr({ workspace = 'r[11-19]', layout_opts = { direction = 'down' } })

hl.window_rule({ match = { workspace = 'r[11-19]' }, scrolling_width = 0.33333 })

The downsize is that it uses fixed workspaces per monitor.

[sebsassi]

Interesting. I'm still on 0.54 anyway, so I can't replicate this. But reading the docs, scrolling_width is a static rule, so would only be applied when the window is first opened. So, unfortunately doesn't fix my main issue with moving existing windows back and forth.

Could solve part of my problem if all my start-up windows opened consistently on the workspaces I want them on, but that's whole another thing.

[ErlanRG]

Agreed. My thinking is that this feature is a must not only for the scrolling layout, but for all layouts for that matter.
I have a much simpler example where this comes very handy:

I'd like to have a specific workspace where the mfact option is set to 75% (global mfact value is 50%).

It should be as easy as setting the option like:

hl.workspace_rule({
    workspace = "4",
    layout = "master",
    layout_opts = { mfact = 0.75 },
})

[rivera-diego]

What you mentioned is fine, but doing it through the workspaces_rule options is a bit dirty in my opinion. To be honest, I've reviewed the Hyprland code and the options already exist; you would just need to add a couple of lines to the layoutopt options to make it work universally. I still don't understand why they don't implement it natively.

[neonvoidx]

Didn't hyprland previously support it? I was using mfact 0.7 on my portrait monitor to a specific workspace (3), which always worked until recently