ManageHook and child windows

older
Re: [xmonad] ManageHook and child...

Raghavendra D Prabhu

23 Jun 2012 23 Jun '12

2:30 p.m.

Hi, I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace. Is there a way to fix / workaround this? Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

Attachments:

attachment.sig (application/pgp-signature — 490 bytes)

Show replies by date

adam vogt

24 Jun 24 Jun

12:56 p.m.

On Sat, Jun 23, 2012 at 2:30 PM, Raghavendra D Prabhu wrote:

...

Hi,

I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace.

Is there a way to fix / workaround this?

Hi Raghavendra, If you run xprop on the dialog windows you find a property like: WM_TRANSIENT_FOR(WINDOW): window id # 0x7c00006 If that's the case, you can use the transience' defined in XMonad.Hooks.ManageHelpers, putting it as the left-most managehook (that is, manageHook = composeAll [ transience' , className =? "a" --> doShift "b", ... ] ) http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageHelpers.html Adam

Raghavendra D Prabhu

25 Jun 25 Jun

7:13 a.m.

Hi, * On Sun, Jun 24, 2012 at 12:56:10PM -0400, adam vogt wrote:

...

On Sat, Jun 23, 2012 at 2:30 PM, Raghavendra D Prabhu wrote:

...
Hi,

I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace.

Is there a way to fix / workaround this?

Hi Raghavendra,

If you run xprop on the dialog windows you find a property like: WM_TRANSIENT_FOR(WINDOW): window id # 0x7c00006

If that's the case, you can use the transience' defined in XMonad.Hooks.ManageHelpers, putting it as the left-most managehook (that is, manageHook = composeAll [ transience' , className =? "a" --> doShift "b", ... ] )

http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageHelpers.html

Adam

_______________________________________________

Thanks, I had tried transience before, albeit for a different purpose I think, let me give it a shot again. Thanks.

...

xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

Raghavendra D Prabhu

7:47 a.m.

Hi, * On Mon, Jun 25, 2012 at 04:43:23PM +0530, Raghavendra D Prabhu wrote:

...

Hi,

* On Sun, Jun 24, 2012 at 12:56:10PM -0400, adam vogt wrote:

...
On Sat, Jun 23, 2012 at 2:30 PM, Raghavendra D Prabhu wrote:

...
Hi,

I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace.

Is there a way to fix / workaround this?

Hi Raghavendra,

If you run xprop on the dialog windows you find a property like: WM_TRANSIENT_FOR(WINDOW): window id # 0x7c00006

If that's the case, you can use the transience' defined in XMonad.Hooks.ManageHelpers, putting it as the left-most managehook (that is, manageHook = composeAll [ transience' , className =? "a" --> doShift "b", ... ] )

http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageHelpers.html

Adam

_______________________________________________

Thanks, I had tried transience before, albeit for a different purpose I think, let me give it a shot again.

Thanks.

...
xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

So, I tried it, it doesn't work for windows like the preferences window of firefox. The reason being that they don't have transient property in their xprop output. However, I did notice WM_CLIENT_LEADER on both windows pointing to same id (that of parent). Further searching lead me to http://tronche.com/gui/x/icccm/sec-5.html "" All top-level, non-transient windows created by a client on the same display as the client leader must have a WM_CLIENT_LEADER property. This property contains a window ID that identifies the client leader window. The client leader window must have a WM_CLIENT_LEADER property containing its own window ID (i.e. the client leader window is pointing to itself). Transient windows need not have a WM_CLIENT_LEADER property if the client leader can be determined using the information in the WM_TRANSIENT_FOR property "" Now, I checked the code and noticed a getTransientForHint being used to check for this. Is there a way to add the above to it? Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

Pablo Olmos de Aguilera C.

7 Jul 7 Jul

6:25 p.m.

On 25 June 2012 07:47, Raghavendra D Prabhu wrote:

...

Hi,

* On Mon, Jun 25, 2012 at 04:43:23PM +0530, Raghavendra D Prabhu wrote:

...
Hi,

* On Sun, Jun 24, 2012 at 12:56:10PM -0400, adam vogt wrote:

...
On Sat, Jun 23, 2012 at 2:30 PM, Raghavendra D Prabhu wrote:

...
Hi,

I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace.

Is there a way to fix / workaround this?

Hi Raghavendra,

If you run xprop on the dialog windows you find a property like: WM_TRANSIENT_FOR(WINDOW): window id # 0x7c00006

If that's the case, you can use the transience' defined in XMonad.Hooks.ManageHelpers, putting it as the left-most managehook (that is, manageHook = composeAll [ transience' , className =? "a" --> doShift "b", ... ] )

http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageHelpers.html

Adam

_______________________________________________

Thanks, I had tried transience before, albeit for a different purpose I think, let me give it a shot again.

Thanks.

...
xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

So, I tried it, it doesn't work for windows like the preferences window of firefox. The reason being that they don't have transient property in their xprop output.

However, I did notice WM_CLIENT_LEADER on both windows pointing to same id (that of parent). Further searching lead me to http://tronche.com/gui/x/icccm/sec-5.html

"" All top-level, non-transient windows created by a client on the same display as the client leader must have a WM_CLIENT_LEADER property. This property contains a window ID that identifies the client leader window. The client leader window must have a WM_CLIENT_LEADER property containing its own window ID (i.e. the client leader window is pointing to itself). Transient windows need not have a WM_CLIENT_LEADER property if the client leader can be determined using the information in the WM_TRANSIENT_FOR property ""

Now, I checked the code and noticed a getTransientForHint being used to check for this. Is there a way to add the above to it?

Regards,

Did you have success? I'm having the same problem... each time firefox spawn a window it appears in a fixed workspace (which is not always the same that I'm using it), also most of them are dialogs, but they tend to tile themselvs which is umconfortable. I was looking to the function you mentioned (getTransientForHint), but I don't know where it is. I see it being called two times in X.H.ManageHelpers and XMonad (Operation.hs), but I still don't understand where to look. Saludos, -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

Brandon Allbery

6:44 p.m.

...

...
Now, I checked the code and noticed a getTransientForHint being used to check for this. Is there a way to add the above to it? Did you have success? I'm having the same problem... each time firefox spawn a window it appears in a fixed workspace (which is not always the same that I'm using it), also most of them are dialogs, but they tend to tile themselvs which is umconfortable.

I started to rework the transients at one point with the above in mind, buit it caused very odd breakages. I never did get the chance to track down exactly what was going on, and at this point I can't do so :( My best luck with Firefox was to doFloat windows whose appName was "Toplevel" (a bit of laziness on the Firefox devs' part...) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Pablo Olmos de Aguilera C.

8:40 p.m.

On 7 July 2012 18:44, Brandon Allbery wrote:

...

...
...
Now, I checked the code and noticed a getTransientForHint being used to check for this. Is there a way to add the above to it? Did you have success? I'm having the same problem... each time firefox spawn a window it appears in a fixed workspace (which is not always the same that I'm using it), also most of them are dialogs, but they tend to tile themselvs which is umconfortable.

I started to rework the transients at one point with the above in mind, buit it caused very odd breakages. I never did get the chance to track down exactly what was going on, and at this point I can't do so :(

There's something I could help?

...

My best luck with Firefox was to doFloat windows whose appName was "Toplevel" (a bit of laziness on the Firefox devs' part...)

Thanks for the tip :). I was giving className Firefox the doFloat property, because I found is less work have to "tile" manually firefox, than float every time firefox creates a dialog (or window) which is kind of often. Still, that doesn't solve the fact that if I move the main window to another workspace, some dialogs appeared in the one I configured through the managehook, so sometimes firefox seems to be unresponsive when really it's waiting from prompt (but on another workspace). I still don't understand though if this is actually a bug on firefox, maybe it deserves to be reported. Regards, -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

Raghavendra D Prabhu

9 Jul 9 Jul

2:25 p.m.

Hi, * On Sat, Jul 07, 2012 at 06:44:40PM -0400, Brandon Allbery wrote:

...

...
...
Now, I checked the code and noticed a getTransientForHint being used to check for this. Is there a way to add the above to it? Did you have success? I'm having the same problem... each time firefox spawn a window it appears in a fixed workspace (which is not always the same that I'm using it), also most of them are dialogs, but they tend to tile themselvs which is umconfortable.

I started to rework the transients at one point with the above in mind, buit it caused very odd breakages. I never did get the chance to track down exactly what was going on, and at this point I can't do so :(

My best luck with Firefox was to doFloat windows whose appName was "Toplevel" (a bit of laziness on the Firefox devs' part...)

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

...

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

So, after the previous post I did some digging in the code. getTransientForHint is from Graphics.X11.Xlib.Extras haskell library. getTransientForHint in turn calls xGetTransientForHint which is in turn a wrapper around the Xlib library. Now, xGetTransientForHint is (from Xlib.h) extern Status XGetTransientForHint( Display* /* display */, Window /* w */, Window* /* prop_window_return */ ); The implementation is provided by libX11 and is: http://www.koders.com/c/fidB6EFD809F184F892950F588CCF941823CF003C65.aspx#L26... So there are two ways to fix this: 1. Fix in libX11 by adding another function or fixing existing one. 2. Fixing getTransientForHint in G.X.X11.Extras by adding another condition to check for WM_CLIENT_LEADER according to ICCWM specs. #2 is more achievable in my opinion (by the maintainer of that library). Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

Brandon Allbery

2:50 p.m.

On Mon, Jul 9, 2012 at 2:25 PM, Raghavendra D Prabhu < raghu.prabhu13@gmail.com> wrote:

...

So, after the previous post I did some digging in the code. getTransientForHint is from Graphics.X11.Xlib.Extras haskell library.

Yes. Do not expect that the X11 binding will be changed to add this; that's the wrong place to put it.

...

So there are two ways to fix this: 1. Fix in libX11 by adding another function or fixing existing one. 2. Fixing getTransientForHint in G.X.X11.Extras by adding another condition to check for WM_CLIENT_LEADER according to ICCWM specs.

And then there's the correct one: extend the *user* of this function, in ManageHelpers, to also do the WM_CLIENT_LEADER check. Modifying a low level X11 binding to do something the bound library does not, namely adding WM_CLIENT_LEADER to a function which is documented to only do WM_TRANSIENT_FOR, is the wrong place to put this. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Raghavendra D Prabhu

3:45 p.m.

Hi, * On Mon, Jul 09, 2012 at 02:50:05PM -0400, Brandon Allbery wrote:

...

On Mon, Jul 9, 2012 at 2:25 PM, Raghavendra D Prabhu < raghu.prabhu13@gmail.com> wrote:

...
So, after the previous post I did some digging in the code. getTransientForHint is from Graphics.X11.Xlib.Extras haskell library.

Yes. Do not expect that the X11 binding will be changed to add this; that's the wrong place to put it.

...
So there are two ways to fix this: 1. Fix in libX11 by adding another function or fixing existing one. 2. Fixing getTransientForHint in G.X.X11.Extras by adding another condition to check for WM_CLIENT_LEADER according to ICCWM specs.

And then there's the correct one: extend the *user* of this function, in ManageHelpers, to also do the WM_CLIENT_LEADER check.

Modifying a low level X11 binding to do something the bound library does not, namely adding WM_CLIENT_LEADER to a function which is documented to only do WM_TRANSIENT_FOR, is the wrong place to put this.

Yes, modifying the manageHelpers would be better and correct; applying same logic modifying either transience or transientTo in ManageHelpers would be incorrect as well (since transience has nothing to do with WM_CLIENT_LEADER), so basically logic (as new ManageHook) needs to be added which moves child windows to parent's workspace based on latter's window id (with interface similar to Query( Maybe Window)) after making sure WM_CLIENT_LEADER is set and window-id != WM_CLIENT_LEADER property value (to avoid the loop).

...

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

...

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

4698

Age (days ago)

4714

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

adam vogt
Brandon Allbery
Pablo Olmos de Aguilera C.
Raghavendra D Prabhu