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.
Having more screens for multi-head setups is not the default behaviour. Yeah, I am not sure if I understand that completely; it seems to me "screen" is the xmonad term for "monitor" or 'physical display', right?
Sorry, I meant to say > Having more _workspaces_ for multi-head setups is not the default > behaviour. But you are correct that, in xmonad, a screen is a monitor.
Boy, I am way outdated~ I thought it was rather "className", and "XMonad.Operations" is part of the core module then?
`className` is just another way of matching windows, I chose `appName` for no particular reason (the former matches on the first string in WM_CLASS and the latter on the second one). Yes, XMonad.Operations is part of the `xmonad` package itself, not contrib.
So one just optionally needs an additional 'liftX screenWorkspace' hook? 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