peterfajdiga
Feature Request - Multi-Monitor Support
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.
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?
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?
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).
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".
@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 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).
@jtaala That sounds pretty elegant, thanks for the explanation. The GNOME API sounds quite powerful.
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
- physical vertical placement is not that rare occasion for laptop users.
- 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.
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.
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.
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.
Another possible 'workaround' could be to change the z-index / stacking order, and have the windows associated with the current monitor always be sorted to be above those on other 'non-focused' monitors.
Not a perfect solution by any means, but it could help?
If I have some time to try karousel on my laptop here and then dig into the code, there is a small chance I can experiment a bit here and submit a PR.
But please don't let this discourage anyone else from attempting this, because it will likely be quite some time until I have the time to explore this.
@sbrl
Another possible 'workaround' could be to change the z-index / stacking order, and have the windows associated with the current monitor always be sorted to be above those on other 'non-focused' monitors.
This is not a bad idea. Unfortunately, it doesn't seem scripts can manipulate stackingOrder, as it's a read-only property.
Niri, a Rust-based scrollable-tiling WM, seems to support multiple monitors from the ground up...
Maybe how it does it could serve as an inspiration?
Maybe how it does it could serve as an inspiration?
Niri is a whole separate compositor. Karousel can only work with what Kwin provides.
Adding three suggestions for some kind of multi-monitor support: I only use tiling on the display with the higher resolution, which is just the laptop display, or (connected to a Dock) the Desktop monitor. For the latter case, I don't need or want any tiling. For this use case, there are two things I would suggest.
- Automatically changing the tiling monitor based on some feature like screen resolution. For now, I use a shortcut of karousel.
- Limiting displaying windows to only the monitor, where tiling is set. Right now, all windows moving over to the other display are being shown, obviously the top and bottom areas are cut.
- I use presets in a way, that I mostly only get two columns on a display. On the other hand, when using both displays, I don't have the same widths set. So, is it possible to have different presets for different displays?
Thanks for this excellent script. Combined with Icons Only Task Managers new feature as of KDE 6.4 of Sorting by horizontal window position makes this a very inuitive and enjoyable experience. I've customised it to my liking and disabled all minimisation actions on windows so Windows are always shown and not minimised. its a far more fluid experience to any tiling window manager or script on KDE I have used.
However... the lack of multi monitor support is unfortunate as thats what I use.
I tried some things to make it work like placing apps on the right hand monitor (I use 2 next to each other) using the inbuilt KDE tiling which works to place apps on that screen and have a similiar look with padding etc. plus they don't move as part of the windows managed by Karousel but its clearly not perfect and karousel managed windows slide behind the windows on the right monitor for instance and task manager icons flick between screens.
I don't actually need virtual desktops any longer due to Karousel and the new Tasks manager feature. I gather Per monitor virtual desktops would solve that by allowing me to use a Virtual Desktop for each monitor but since that Feature request is 20 years old in KDE I doubt that'll happen any time soon.
I like using Karousel so much I found myself looking at wide screen monitors online and trying to code a patch myself using AI which did not work as I'm not a coder. I'd be happy to donate some $$ to get this included if that were an option.
Thanks again for this great script in any case.
One thing I feel that works against multi-monitor support is maybe how it determines when it is necessary to scroll on focus. I use two monitors horizontally as a fake widescreen with the only scroll when necessary setting enabled but it doesn't seem to consider the non-primary screen. I will click a window that is on the non-primary display and expect to be able to input immediately but it will move to primary display first. This can be problematic if I was intending to click again on a button.
Actual:
Expected:
Just my two cents, as I didn’t dig enough to be sure this is possible, but it seems you can run kwin scripts inside of plasmoids: see kwin-script-launcher or kwin-script-workflow. If so, a solution, as long as you chose the one grid per monitor option, would be to add a karousel plasmoid per monitor where you want STWM.
I think the best solution would be to:
- align all monitors vertically
- create "fake" monitor layout within plugin, where the user could align them horizontally if he wanted
- add keybinds to "focus monitor left / up / down/ bottom" that use "fake" layout as well as move window to monitor in the same way
- handle mouse cursor warp to another monitor in the "fake" layout (if for example I have 2 monitors and create fake horizontal layout, then whenever I move my mouse to the right edge of the left monitor, it's being warped to the right monitor).
The plugin could initially detect whether the monitors are aligned correctly (if possible), ask the user whether he wants to align them automatically and only activate in multi-monitor mode if they are aligned.
Maybe as step one absolute minimum support could allow the user to choose one monitor as the main one where windows are locked to and scroll from?
Right now it randomly switches between them whenever the system wakes up from sleep which is not workable for me at least (is there some workaround for this?).
