xmonad: shift all new windows to currently focused workspace
Asked Answered
T

0

8

I know that it's possible to set certain programs to spawn in certain workspaces like so:

myManageHook = composeAll
    [ classname =? "XTerm" --> doShift "3" ]
main = xmonad $ defaultConfig
    { manageHook = myManageHook <+> manageHook defaultConfig }

So that all instances of Xterm will spawn in workspace "3". What I want to do is make all new programs spawn in the workspace which is in focus when they are started, such that if, for example, I'm in workspace "1" and start firefox, then quickly switch to workspace "2", the firefox window will stay in workspace "1".

I was thinking of something to the effect of

import qualified XMonad.StackSet as W

myManageHook = composeAll
    [ classname =? ".*" --> doShift currentTag ]
main = xmonad $ defaultConfig
    { manageHook = myManageHook <+> manageHook defaultConfig }

which obviously doesn't work, but hopefully you get the idea.

My question is quite similar to this one in intent, but I want all programs to spawn in the intially focused workspace however I open them (dmenu, from a terminal, etc.)

Triune answered 23/11, 2013 at 3:52 Comment(15)
I assume your example should read this way instead: "I'm in workspace '1' and start firefox, then quickly switch to workspace '2', the firefox window will stay in workspace '1'.". If so, what you're asking for is simply not possible with X's architecture. Sorry.Bernardobernarr
Fixed typo. I'm sure you're much better versed in X architercture than I am, but are you certain it's impossible? I was under the impression that this kind of behaviour is in fact default in the spectrwm window manager, but I will double check this later today.Triune
Confirmed: in spectrwm, windows always (as far as I can tell) open in the workspace that's in focus when they're invoked. Opening methods tested: from inside xterm, using dmenu, using spectrwm keybindings as follows: program[firefox] = firefox bind[firefox] = MOD+fTriune
Sounds like magic. Would you be willing to do another test for me? I've written a short Haskell program that pauses ten seconds, opens a window, pauses ten seconds, and quits. Will you try this one, too? Perhaps spectrwm and firefox are cooperating somehow; this program definitely isn't cooperative and will test that hypothesis. If they are cooperating somehow, it may be possible to find out how, and do something similar in xmonad. Then you'll have a solution for cooperative programs (but obviously not for uncooperative ones -- I still believe that's impossible).Bernardobernarr
I hope you have a null hypothesis ready: your script behaves just like firefox!Triune
I've got sad news for you -- I'm completely stumped. As far as I know the behavior you're describing just doesn't make sense: there's no (reliable) way for a window manager to connect a new window to a process, and even if there were, there's no (reliable) way to know which workspace was active at the moment a process started.Bernardobernarr
Fair enough, thanks for your help anyway.Triune
@Triune If you are hell-bent, the spectrwm source code is available to read on github.Bodnar
@DanielWagner In the spectrwm source code, there's a bit (line 8130 at least) that tries to get a PID based on the window highlighted, to figure out which workspace the window belongs to. I guess that's a good enough approximation for many applications, although it's certainly not reliable...Bodnar
@Bodnar Right, that's the kind of thing I was talking about when I said "perhaps spectrwm and firefox are cooperating somehow". It checks a bunch of X properties of the window that's starting up: _NET_WM_PID, _SWM_PID, _SWM_WS, and whether the window is a transient with a parent. (xmonad offers ways to check such stuff, too.) The code snippet I posted doesn't set any of these properties and does not create a transient window: it offers no cooperation. Which is why I say I'm stumped!Bernardobernarr
@DanielWagner Ah, you're right. That's weird.Bodnar
A friend of mine who's using spectrwm has recently mentioned to me that this functionality broke in a recent update, and that apparently it has something to do with a library called ld_preload. I know this is vague as hell and likely not helpful, but I thought I'd post it here on the off-chance...Triune
An admin on this forum post confirms that the behaviour is achieved with some kind of LD_PRELOAD hack, but doesn't provide detailsTriune
I believe the code here is responsible? I'm afraid it's beyond my capabilities to understand, however.Triune
Update: this XMonad library claims to achieve this result, but it doesn't actually seem to work for me.Triune

© 2022 - 2024 — McMap. All rights reserved.