[xmonad] managehook: How to shift apps to a screen in dual-head?

[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.

>> 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