Toggle Window (Always Below <-> Always Above)

Hi, using AvoidStruts I have implemented some way to show my status bar only while holding my modkey. Unfortunatly this method is quite slow and ineffective as all windows on the current screen resize and redraw when pressing the modkey. Instead I'm searching for a way to reorder the stackset such that my dzen window appears either above all other windows (while the modkey is pressed) or below all other. Some implementation like that would although solve another issue I'm experiencing: When I restart xmonad my dzen bar is suddenly on top of all other windows until I create a new one, that then enables all other windows to again cover the status bar. Someone got an idea how to implement such an behavior based on what is already done with those eventhooks in my current configuration? (see line 130-152) Best regards, Jan P.S. I have attached my xmonad configuration for reference. -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

I too am very curious as to how to (properly) do this. I have not been
able to find a solution.
On Tue, Jan 25, 2011 at 00:32, Jan-David Quesel
Hi,
using AvoidStruts I have implemented some way to show my status bar only while holding my modkey. Unfortunatly this method is quite slow and ineffective as all windows on the current screen resize and redraw when pressing the modkey. Instead I'm searching for a way to reorder the stackset such that my dzen window appears either above all other windows (while the modkey is pressed) or below all other.
Some implementation like that would although solve another issue I'm experiencing: When I restart xmonad my dzen bar is suddenly on top of all other windows until I create a new one, that then enables all other windows to again cover the status bar.
Someone got an idea how to implement such an behavior based on what is already done with those eventhooks in my current configuration? (see line 130-152)
Best regards, Jan
P.S. I have attached my xmonad configuration for reference.
-- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany
Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk0+io8ACgkQzWWUYNynIPEJJACfcluX6sDooiBSRO2M8JbWc9Zw X7AAnR4xCN1ylohou3A7OwEn9y2JauHM =an5t -----END PGP SIGNATURE-----
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

As an idea of how to do this, I might have tried doIgnore on dzen
window as described there:
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Extending.html#15
And then assign to keys some shell or xmonad commands that move that
window in and out of the screen (maybe even roll it in/out animated).
Another idea is to use doFloat like described on above link and then
assign to keys the hide and reveal functions described here:
http://xmonad.org/xmonad-docs/xmonad/XMonad-Operations.html#v%3Ahide
It's too bad my Haskell is too bad to express this
On 1/26/11, Israel Jacques
I too am very curious as to how to (properly) do this. I have not been able to find a solution.
On Tue, Jan 25, 2011 at 00:32, Jan-David Quesel
wrote: Hi,
using AvoidStruts I have implemented some way to show my status bar only while holding my modkey. Unfortunatly this method is quite slow and ineffective as all windows on the current screen resize and redraw when pressing the modkey. Instead I'm searching for a way to reorder the stackset such that my dzen window appears either above all other windows (while the modkey is pressed) or below all other.
Some implementation like that would although solve another issue I'm experiencing: When I restart xmonad my dzen bar is suddenly on top of all other windows until I create a new one, that then enables all other windows to again cover the status bar.
Someone got an idea how to implement such an behavior based on what is already done with those eventhooks in my current configuration? (see line 130-152)
Best regards, Jan
P.S. I have attached my xmonad configuration for reference.
-- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany
Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk0+io8ACgkQzWWUYNynIPEJJACfcluX6sDooiBSRO2M8JbWc9Zw X7AAnR4xCN1ylohou3A7OwEn9y2JauHM =an5t -----END PGP SIGNATURE-----
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Hi, first let me thank you for your suggestion. Now lets take a quick look at what is currently done and where the implementation issues lie regarding your suggestions. doIgnore is what is currently done. manageDocks is just short for checkDock --> doIgnore. Thats also whats probably causing the issue with dzen being on top after restart. The question is how to reveal it in a convenient way. I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState. The same issue occurs with your 2nd suggestion. How do I get the window in the eventHook to call reveal/hide on it? Any suggestions? Jan P.S. I think the X.L.Monitor packages looks interesting but it still has a todo regarding the same task, as it also needs to store which window it manages. On Wed, Jan 26, 2011 at 07:46:36PM +0300, kevind256 wrote:
As an idea of how to do this, I might have tried doIgnore on dzen window as described there: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Extending.html#15 And then assign to keys some shell or xmonad commands that move that window in and out of the screen (maybe even roll it in/out animated).
Another idea is to use doFloat like described on above link and then assign to keys the hide and reveal functions described here: http://xmonad.org/xmonad-docs/xmonad/XMonad-Operations.html#v%3Ahide
It's too bad my Haskell is too bad to express this
On 1/26/11, Israel Jacques
wrote: I too am very curious as to how to (properly) do this. I have not been able to find a solution.
On Tue, Jan 25, 2011 at 00:32, Jan-David Quesel
wrote: Hi,
using AvoidStruts I have implemented some way to show my status bar only while holding my modkey. Unfortunatly this method is quite slow and ineffective as all windows on the current screen resize and redraw when pressing the modkey. Instead I'm searching for a way to reorder the stackset such that my dzen window appears either above all other windows (while the modkey is pressed) or below all other.
Some implementation like that would although solve another issue I'm experiencing: When I restart xmonad my dzen bar is suddenly on top of all other windows until I create a new one, that then enables all other windows to again cover the status bar.
Someone got an idea how to implement such an behavior based on what is already done with those eventhooks in my current configuration? (see line 130-152)
Best regards, Jan
P.S. I have attached my xmonad configuration for reference.
-- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany
Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk0+io8ACgkQzWWUYNynIPEJJACfcluX6sDooiBSRO2M8JbWc9Zw X7AAnR4xCN1ylohou3A7OwEn9y2JauHM =an5t -----END PGP SIGNATURE-----
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

Now lets take a quick look at what is currently done and where the implementation issues lie regarding your suggestions.
doIgnore is what is currently done. manageDocks is just short for checkDock --> doIgnore. Thats also whats probably causing the issue with dzen being on top after restart.
Frankly I don't see the problem with that doIgnore is "currently done": I think it's checkDock is causing your problem that "all windows on the current screen resize and redraw when pressing the modkey". If you use doIgnore alone, there won't be a checkDock, so there shouldn't be any resizes.
The question is how to reveal it in a convenient way.
I mentioned that there could be xmonad functions to do that, but if not, I almost sure you can find command line utilities for Xorg to move any window in/out of screen. They could find the window by one of the parameters returned by these commands (run in terminal and click desired window to see): xprop|grep CLASS xprop|grep ^WM_NAME
I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState.
Neither do I. But not sure this is needed.
The same issue occurs with your 2nd suggestion.
Which issue? doFloat isn't "done currently".
How do I get the window in the eventHook to call reveal/hide on it?
Haskell expert wanted.
Any suggestions?
Run out of pool.
Jan
P.S. I think the X.L.Monitor packages looks interesting but it still has a todo regarding the same task, as it also needs to store which window it manages.

Hi, On Thu, Jan 27, 2011 at 02:59:55PM +0300, kevind256 wrote:
Now lets take a quick look at what is currently done and where the implementation issues lie regarding your suggestions.
doIgnore is what is currently done. manageDocks is just short for checkDock --> doIgnore. Thats also whats probably causing the issue with dzen being on top after restart.
Frankly I don't see the problem with that doIgnore is "currently done": I think it's checkDock is causing your problem that "all windows on the current screen resize and redraw when pressing the modkey". If you use doIgnore alone, there won't be a checkDock, so there shouldn't be any resizes.
the checkDock part is just for identifying the dzen window. so what causes the redraw is essentially the fact that all windows are moved out of the way (by inserting a gap at the top) such that one can see the "ignored" window...
The question is how to reveal it in a convenient way.
I mentioned that there could be xmonad functions to do that, but if not, I almost sure you can find command line utilities for Xorg to move any window in/out of screen. They could find the window by one of the parameters returned by these commands (run in terminal and click desired window to see): xprop|grep CLASS xprop|grep ^WM_NAME
yeah the functions are there, but doIgnore removes the window from the stackset. therefore you cannot search the stackset and filter it by those properties anymore.
I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState.
Neither do I. But not sure this is needed.
The same issue occurs with your 2nd suggestion.
Which issue? doFloat isn't "done currently".
I was referencing the "how do I get a window handle issue" here.
How do I get the window in the eventHook to call reveal/hide on it?
Haskell expert wanted.
yeah I think that's what we need right now :) Regards, Jan -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

the checkDock part is just for identifying the dzen window. so what causes the redraw is essentially the fact that all windows are moved out of the way (by inserting a gap at the top) such that one can see the "ignored" window...
That's wrong, as I saw it. I tried using doIgnore on Pidgin window, and it just stayed above all other windows, without creating any gaps. Gaps are created by layouts, and doIgnore is exactly what excludes window from any layout.
I mentioned that there could be xmonad functions to do that, but if not, I almost sure you can find command line utilities for Xorg to move any window in/out of screen. They could find the window by one of the parameters returned by these commands (run in terminal and click desired window to see): xprop|grep CLASS xprop|grep ^WM_NAME
yeah the functions are there, but doIgnore removes the window from the stackset. therefore you cannot search the stackset and filter it by those properties anymore.
Then, as I said, you could try command-line tools, such as "wmctrl -r <WIN> -b add,hidden" should do this. A simple Google request might also help: http://www.google.com/search?client=ubuntu&channel=fs&q=linux+command+hide+window&ie=utf-8&oe=utf-8

On Thu, Jan 27, 2011 at 06:42:51PM +0300, kevind256 wrote:
the checkDock part is just for identifying the dzen window. so what causes the redraw is essentially the fact that all windows are moved out of the way (by inserting a gap at the top) such that one can see the "ignored" window...
That's wrong, as I saw it. I tried using doIgnore on Pidgin window, and it just stayed above all other windows, without creating any gaps. Gaps are created by layouts, and doIgnore is exactly what excludes window from any layout.
nah, the avoidStruts stuff inserts the gaps. if you ignore a window other windows will be positioned on top of it if you do not reserve the space. and the issue is how to get them back to the front and instantanously get them back without inserting gaps into the layout for a short period of time (as thats rather slow in some cases).
I mentioned that there could be xmonad functions to do that, but if not, I almost sure you can find command line utilities for Xorg to move any window in/out of screen. They could find the window by one of the parameters returned by these commands (run in terminal and click desired window to see): xprop|grep CLASS xprop|grep ^WM_NAME
yeah the functions are there, but doIgnore removes the window from the stackset. therefore you cannot search the stackset and filter it by those properties anymore.
Then, as I said, you could try command-line tools, such as "wmctrl -r <WIN> -b add,hidden" should do this.
A simple Google request might also help: http://www.google.com/search?client=ubuntu&channel=fs&q=linux+command+hide+window&ie=utf-8&oe=utf-8
same problem from the command line. as one used doIgnore, the window isnt managed anymore and thus does not appear in the output of wmctrl -l. so receiving the windowid is the problem here again. Jan -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

if you ignore a window other windows will be positioned on top of it if you do not reserve the space. and the issue is how to get them back to the front and instantanously get them back without inserting gaps into the layout for a short period of time (as thats rather slow in some cases).
Well for me, it was on top. I guess that depends on window parameters. Check dzen options or command-line tools that might set always-on-top or similar.
same problem from the command line. as one used doIgnore, the window isnt managed anymore and thus does not appear in the output of wmctrl -l. so receiving the windowid is the problem here again.
That might be because wmctrl talks to window manager, and xmonad says "I don't know such window!". You could search for other command-line tools.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/27/11 05:11 , Jan-David Quesel wrote:
The question is how to reveal it in a convenient way. I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState.
You don't want to store a StackSet; just store the dzen window (`ask' in the manageHook) in ExtensibleState: this *does* work unless someone broke it recently. Then you can retrieve it in e.g. a keybinding and hide/show as appropriate. (I would arrange for it not to reserve space/set struts, hide it by default, and map it while the mod key is held; it should in any case be doIgnore-d.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1E3GoACgkQIn7hlCsL25W2bgCdEy0rgR5HnIzfQAV/+w+2mQ0N PX0AoMup9Oup9/z+LcVg/0SJvW6nzn9E =XN+3 -----END PGP SIGNATURE-----

Hi, On Sat, Jan 29, 2011 at 10:35:06PM -0500, Brandon S Allbery KF8NH wrote:
On 1/27/11 05:11 , Jan-David Quesel wrote:
The question is how to reveal it in a convenient way. I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState.
You don't want to store a StackSet; just store the dzen window (`ask' in the manageHook) in ExtensibleState: this *does* work unless someone broke it recently. Then you can retrieve it in e.g. a keybinding and hide/show as appropriate. (I would arrange for it not to reserve space/set struts, hide it by default, and map it while the mod key is held; it should in any case be doIgnore-d.)
ah yeah that sounds like a good idea. might have been a missunderstanding on my side that I didnt come to think of just using ask to retrieve the window. I'm now trying to use the following manageHook checkDock --> do win <- ask WindowDump windows <- XS.get :: X WindowDump XS.put $ WindowDump (win:windows) doHideIgnore where WindowDump is just data WindowDump = WindowDump ([Window]) deriving (Read, Show, Typeable) instance ExtensionClass WindowDump where initialValue = WindowDump [] extensionType = PersistentExtension Unfortunatly this just gives type errors. Is there a way to store the window in the managehook or has this to be done somewhere else? Regards, Jan -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

Hi, On Sat, Jan 29, 2011 at 10:35:06PM -0500, Brandon S Allbery KF8NH wrote:
On 1/27/11 05:11 , Jan-David Quesel wrote:
The question is how to reveal it in a convenient way. I dont even really have an idea how to find the dzen window in my event hook, as I cannot store a WindowSet in the manageHook as its not compatible with ExtensibleState.
You don't want to store a StackSet; just store the dzen window (`ask' in the manageHook) in ExtensibleState: this *does* work unless someone broke it recently. Then you can retrieve it in e.g. a keybinding and hide/show as appropriate. (I would arrange for it not to reserve space/set struts, hide it by default, and map it while the mod key is held; it should in any case be doIgnore-d.)
ah yeah that sounds like a good idea. might have been a missunderstanding on my side that I didnt come to think of just using ask to retrieve the window. I'm now trying to use the following manageHook checkDock --> do win <- ask WindowDump windows <- XS.get :: X WindowDump XS.put $ WindowDump (win:windows) doHideIgnore where WindowDump is just data WindowDump = WindowDump ([Window]) deriving (Read, Show, Typeable) instance ExtensionClass WindowDump where initialValue = WindowDump [] extensionType = PersistentExtension Unfortunatly this just gives type errors. Is there a way to store the window in the managehook or has this to be done somewhere else? Regards, Jan -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

På Mon, 31 Jan 2011 10:52:05 +0100, skrev Jan-David Quesel
ah yeah that sounds like a good idea. might have been a missunderstanding on my side that I didnt come to think of just using ask to retrieve the window.
I'm now trying to use the following manageHook checkDock --> do win <- ask WindowDump windows <- XS.get :: X WindowDump XS.put $ WindowDump (win:windows) doHideIgnore
XS.get and XS.put live in the X monad, while manage hooks live in the Query monad. The solution is to lift the calls, thus: checkDock --> do win <- ask WindowDump windows <- liftX XS.get :: Query WindowDump liftX $ XS.put $ WindowDump (win:windows) doHideIgnore -- Audun Skaugen

Hi, On Mon, Jan 31, 2011 at 12:43:00PM +0100, Audun Skaugen wrote:
På Mon, 31 Jan 2011 10:52:05 +0100, skrev Jan-David Quesel
: ah yeah that sounds like a good idea. might have been a missunderstanding on my side that I didnt come to think of just using ask to retrieve the window.
I'm now trying to use the following manageHook checkDock --> do win <- ask WindowDump windows <- XS.get :: X WindowDump XS.put $ WindowDump (win:windows) doHideIgnore
XS.get and XS.put live in the X monad, while manage hooks live in the Query monad. The solution is to lift the calls, thus:
checkDock --> do win <- ask WindowDump windows <- liftX XS.get :: Query WindowDump liftX $ XS.put $ WindowDump (win:windows) doHideIgnore
ah nice. That seems to work. Now on to the next issue. Floating the docks seems to kinda work. However it has lots of ugly side effects, such as being able to move the windows around etc. When I call doIgnore on the window and later try to call reveal on it, it does stay in the background... same for doHideIgnore and reveal. Is there a function I can call on a window to get on top of other windows? Regards, Jan -- Jan-David Quesel Carl von Ossietzky Universität Oldenburg Department of Computing Science Correct System Design D-26111 Oldenburg, Germany Phone: +49 (0)441 798-2376 Fax: +49 (0)441 798-2965

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/31/11 09:35 , Jan-David Quesel wrote:
Is there a function I can call on a window to get on top of other windows?
io (raiseWindow win) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1G5oQACgkQIn7hlCsL25UJcgCff5JvwIVEN1N5BRl8R4EPIUYi x9cAn1fV2+QThsMl/hcX7DBKRZ8EPWR4 =o0w/ -----END PGP SIGNATURE-----
participants (6)
-
Audun Skaugen
-
Brandon S Allbery KF8NH
-
Israel Jacques
-
Jan-David Quesel
-
Jan-David Quesel
-
kevind256