Feature Request - Multi-Monitor Support

[crestofthebeast]

I love scrollable WMs, but would love to replace my usage of PaperWM with something not gnome-based for power/native app reasons.

Is multi monitor support on the roadmap at all, or is it out of scope/just too much effort?

Thanks for the awesome work.

edit: Gave this a quick test, for what it's worth I almost... enjoy the current behaviour?

My secondary monitors (a drawing tablet + larger monitor for content viewing/discord on the side) see little movement compared to the primary one, and this sort of behaviour is totally workable for me.

Regardless, full support would be greatly loved.

[peterfajdiga]

Hi, thanks for the input!

I don't really know how to achieve this, unfortunately. To keep this comment shorter, I'll assume the monitors are arranged horizontally. I see two ways to support this: treat all the monitors as one wide monitor and spread a single grid (a workspace with columns of windows) across all of them; or create multiple grids - one grid per monitor.

The one big grid option would routinely position some windows so that they're split across two monitors. Maybe this could be mitigated with some kind of monitor-aware scrolling and window arrangement, but it would not be trivial.

The one grid per monitor option would have the issue that the off-grid windows (those that are scrolled out of view) would be visible on an adjacent monitor, clashing with the windows that are supposed to be on this adjacent monitor. I would need to somehow pin windows to specific monitors so that they only appear there (even if they're partially off-screen), but I don't know if KWin supports this, it's not exposed by the KWin Scripting API.

If the issues with both options were fixable, which one would you prefer?

[crestofthebeast]

One grid per monitor is the way PaperWM handles it, and probably my favourite.

My first instinct is to use virtual desktop functionality (I believe PaperWM does this, with one workspace per monitor), but I'm unsure if kwin supports having different monitors viewing different desktops?

[peterfajdiga]

I agree, I would prefer one grid per monitor as well. Unfortunately, it seems KWin doesn't support per-monitor virtual desktops: https://bugs.kde.org/show_bug.cgi?id=107302 (note that the reporter achieved some success by disabling Xinerama).

[jtaala]

I believe PaperWM does this,

No, Gnome also doesn't support one workspace per monitor - it's essentially treats it as a single workspaces across monitors.

In PaperWM, we create our own paradigm and separate the Gnome workspace (across monitors) into PaperWM "spaces" (which basically gives us one PaperWM "space" per monitor). We have a mutter actor active on monitors that detects when the mouse cursor enters a different monitor's space, and hence activates that PaperWM "space".

[peterfajdiga]

@jtaala Thank you for the insight! May I also ask how PaperWM deals with windows that are partly on one monitor and partly on another? Are they obscured by the clutter actor on the monitor where they shouldn't be visible? (I'm not at all familiar with Clutter)

[jtaala]

@jtaala Thank you for the insight! May I also ask how PaperWM deals with windows that are partly on one monitor and partly on another? Are they obscured by the clutter actor on the monitor where they shouldn't be visible? (I'm not at all familiar with Clutter)

Close - so we arrange windows into a swipeable actor (e.g. swipeable with 3-finger left/right) that is "clipped" to the monitors bounds (which essentially hides the window overlaps across monitors).

[peterfajdiga]

@jtaala That sounds pretty elegant, thanks for the explanation. The GNOME API sounds quite powerful.

[keighrim]

The one grid per monitor option would have the issue that the off-grid windows (those that are scrolled out of view) would be visible on an adjacent monitor, clashing with the windows that are supposed to be on this adjacent monitor.

A quick and dirty workaround can be having (forcing?) users to align monitors vertically in system settings. I understand that'd be a great confusion moving mouse around, if the monitors are physically horizontally placed, but

1. physical vertical placement is not that rare occasion for laptop users.
2. when in a tiling environment, I'd prefer keyboard shortcuts to move focus and windows between monitors anyway, so I'm willing to trade off the mouse movement confusion with the convenience of having two screens.

[peterfajdiga]

That's true. The user could arrange monitors vertically to work around this problem. I wouldn't force users to do this, though. If anything, I'd just implement multi-monitor support and then it'd be up to the user to decide how to deal with the off-screen windows problem. However, multi-monitor support is not a priority.

[grindstm]

I have a suggestion in the interim. Currently, I have a second monitor vertically stacked which I occasionally use. I must disable karousel when I use this monitor because karousel will move all my windows to whichever monitor the cursor is currently on. Dizzying.

Maintaining the karousel only on the primary monitor and allowing vanilla window behavior on second monitors would be a significant improvement.

[Makrennel]

I would suggest as an alternative to pushing windows off the screen on multi-monitor setups, how about simply pushing windows into a stack by the edge which is adjoined to another monitor so they remain on the same monitor and do not cross the threshold? This would at least work around the grid-per-monitor functionality without having to fight with the fact that kwin doesn't allow separate per-monitor workspaces.