Thanks for your response! Am 13.01.22 um 07:48 schrieb Solid:

Hi,

On Wed, Jan 12 2022 22:40, 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

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?

On the other hand, maybe "screen" might be the combined 'view port' of all connected displays I am currently looking at; I guess that's the xinerama thing (and why the same wallpaper is shared [and not repeated on each monitor]). – Call me a dummy, but that's still not quite clear to me though I consulted xmonad docs and configurations; hence I am asking...

...

But how to initially shift programs to workspaces on a specific monitor (in myManageHook)? There is screenWorkspace[1] to get the workspace of some monitor, which could then be used in a manageHook as normal

-- for monitor 1 (≡ the second one; we are 0-indexed) appName =? "my-app" --> maybe mempty doShift =<< liftX (screenWorkspace 1)

Tony

[1]: https://hackage.haskell.org/package/xmonad-0.17.0/docs/XMonad-Operations.htm...

Boy, I am way outdated~ I thought it was rather "className", and "XMonad.Operations" is part of the core module then? 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.

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

Edit in addition to last post:

Am 17.01.22 um 16:40 schrieb mito:

...

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

In other words: How to make clients sticky to a monitor/screen (in KDE5/Plasma) when changing workspaces even if the other screen is empty (to not swap them back by an extra mod-{e,w,r})?

It's quite frustrating when properly arranged clients are always swapped to the wrong screen after it happened that was empty before on another workspace. Now (in dual-head), when switching workspaces, only one monitor/screen switches. So it would be of help *all screens* switch, too, and hence

Additional edit (2): Am 17.01.22 um 17:13 schrieb mito: the complete workspace's 'view port'. – IMO "import qualified Graphics.X11.Xinerama" should do this, and that module treats both monitors as one in combination. As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I missing something in KDE5?

Am 17.01.22 um 18:14 schrieb Brandon Allbery:

On Mon, Jan 17, 2022 at 12:09 PM mito wrote:

...

Now (in dual-head), when switching workspaces, only one monitor/screen switches. So it would be of help *all screens* switch, too, and hence the complete workspace's 'view port'. – IMO "import qualified Graphics.X11.Xinerama" should do this, and that module treats both monitors as one in combination. Importing a module in Haskell only makes names available; it does not and can not perform any actions. Additionally, that is a low level module which exposes the X11-layer multiscreen support, not xmonad's.

If you really want both screens to switch at the same time, you might be interested in https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Action.... Thanks, will look into it! ^^

...

As mentioned earlier, it works in Trinity (a.k.a. TDE=KDE3.5), so am I missing something in KDE5? Are you talking about Trinity's window manager, or xmonad? xmonad (and dwm) divide workspaces up between monitors; most window managers treat a workspace as spanning all monitors.

Sorry – to be more precisely: Xmonad as the WM (replacing kwin_x11) in Trinity.