Am 14.01.22 um 08:42 schrieb Solid:
On Thu, Jan 13 2022 16:50, mito wrote:
I got a proper dual-head xrandr configuration with one monitor in landscape view and one in portrait view. So in xmonad I have 2x10 workspaces, which is fine. Are you using IndependentScreens or something? Well, no, though I read about it.
But I do have:
import qualified Graphics.X11.Xinerama Then you shouldn't have 2x10 workspaces but only your "original" 10, since both monitors can use them. OK, now it seems to work as you say – in KDE5/Plasma. My problem was in Trinity, which is KDE3.5; screens are managed a bit different there. So one just optionally needs an additional 'liftX screenWorkspace' hook?
On the other side, clients in Trinity don't swap monitors automatically if there was an empty screen; which was handy. They just were sticky if you don't shift them manually. Now in Plasma clients swap monitors again though I changed from "W.greedyView" to "W.view"...
Sounds great! And compiles well. – But yet it has no effect, whatever screenWorkspace {0,1} (or {app,class}Name) I choose: the workspace fits, but the monitor selection is ignored. That's weird, because I just tried it and it actually works for me. Specifically I used something like
myManageHook :: ManageHook myManageHook = mconcat [ -- ... other stuff ... , className =? "mpv" --> maybe mempty doShift =<< liftX (screenWorkspace 1) ]
for my manageHook and now mpv does indeed seem to always spawn on the currently focused workspace of the second monitor.
Tony Well, alternatively one could spawn an app via hotkeys with an additional "xdotool key Super_L+{w,e}" (w/ mod4-mask).
Is there already a hotkey for toggling 'clients on monitors switching'? (I mean, client A on screen 0 shifts to screen 1 & client B on screen 1 shifts to screen 0 simultaneously.)