Feature Request - Multi-Monitor Support #3
Comments
|
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). |
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) |
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. |
… simpler implementation (#751) @Lythenas, @Thesola10, I've been thinking about this one for a while: PaperWM uses a very curious approach to implement a "one space per monitor" paradigm (see [my response](peterfajdiga/karousel#3 (comment)) to a question of how PaperWM does this). Unfortunately this approach is quite complex and exhibits many side-effects that have required many workarounds (which often causes further issues). This PR replaces this approach with a simpler `PointerWatcher` implementation (a Gnome supported implementation to monitor mouse pointer movements). Moving to this approach provides the following advantages: - switch to a Gnome supported feature to detect when mouse pointer moves to another monitor (instead of an unsupported, custom, error-prone implementation); - significantly simplifies the codebase for PaperWM's multimonitor support; - replaces around ~164 lines of (now) unneeded code with ~31 lines; - removes a complex part of multimonitor support and would allow us to add simple behaviours (based on user preference) like #389; _Note: we actually already use the `PointerWatcher` approach for multi-monitor drag/drop support - so this PR is essentially removing the other approach and adding a "activate space" method to the `PointerWatcher`._ @Lythenas and @Thesola10 - could you give this PR branch a test? I'll set it as a draft atm given it's quite a large change and I'm sure there might be some side-effects from this. @Thesola10 - I note that this may impact some of your touch signals, although, we no longer have the ClickOverlay element blocking actions so it may turn out better (just a hypothesis).
A quick and dirty workaround can be having (forcing?) users to align monitors vertically in system settings.
|
|
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 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.
The text was updated successfully, but these errors were encountered: