On Thu, Nov 04, 2010 at 10:24:26AM +0100, Hannes Schueller wrote: > This happens with GTK applications. Could be the same with other > 'graphical' (i.e. X-based) programs, but I have no way of checking. > Steps to reproduce: > > - open an application on tag 1 > - send the applicaton to another tag > - have the application open a dialogue window (e.g. file open dialogue) > - the dialogue window appears on tag 1 instead of the current one > > It is not a problem of an individual application, I tested it with > many different ones.
I’ve seen this behaviour in all versions of scrotwm, too.
The reason why this happens is that, when an application is spawned inside
scrotwm, the libswmhack library that is LD_PRELOADed intercepts the call to
XCreateWindow, reads the _SWM_WS environment variable, and stores that value
in a window property; that window property is then used by scrotwm to decide
which workspace the window belongs to.
The fact is, the _SWM_WS environment variable doesn’t change over the lifetime
of a window: if you spawn a terminal on workspace 1, the terminal environment
contains _SWM_WS=0, and that environment is inherited by any program spawned
from within that terminal; moving the terminal to, say, workspace 5 doesn’t
alter the value of the _SWM_WS environment variable, so any program spawned
from that terminal will always be associated to workspace 1.
To test this out, you can spawn a terminal in workspace 1 and the execute
$ _SWM_WS=5 someprogram
you’ll see that someprogram is spawned on workspace 4.
I’m personally not sure how useful libswmhack is, and not LD_PRELOADing it
fixes this bug, but may cause other problems.
I’ve CCed Marco to see what he thinks of it.
Cheers.
--
Andrea Bolognani <[email protected]>
Resistance is futile, you will be garbage collected.
signature.asc
Description: Digital signature
