"minimize" + "boringAuto" in Full-layout: focusUp and focusDown don't change focus
Hi I am new to xmonad. I use version 0.9. I am trying to get "minimize" and "boringAuto" working together, like described here: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Minimize.html "The module is designed to work together with XMonad.Layout.BoringWindows so that minimized windows will be skipped when switching the focus window with the keyboard. Use the boringAuto function." The layout is: myLayout = boringAuto $ minimize (Full ||| tiled ||| Mirror tiled) where tiled = Tall nmaster delta ratio nmaster = 1 delta = 1/12 ratio = 1/2 Everythings works fine, except the Full-mode. In Full-mode the functions focusUp and focusDown from XMonad.Layout.BoringWindows don't switch to the next or previous window. They do nothing. I would like to be able to cycle in Full-mode through all windows but the minimized windows. Is there anything, I can do? Ralph
* On Saturday, December 19 2009, Ralph Hofmann wrote:
Hi
I am new to xmonad. I use version 0.9.
I am trying to get "minimize" and "boringAuto" working together, like described here: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Minimize.html ... Everythings works fine, except the Full-mode. In Full-mode the functions focusUp and focusDown from XMonad.Layout.BoringWindows don't switch to the next or previous window. They do nothing.
I would like to be able to cycle in Full-mode through all windows but the minimized windows. Is there anything, I can do?
Ralph
In the case of Full, boringAuto is doing exactly as it is supposed to do. I'm not sure that adding a special case to it makes sense to address this situation; that would be more surprising behavior; lets say you minimize all windows except one, should boringAuto now let you focus between windows? Then again, maybe such a thing should be made an option, since that change would be much cleaner and reliable than the following hack based on checking your layout description, and then decide to send whichever message you want based on that:
fu,fd :: X () fu = checkDescr focusUp (windows W.focusUp) "Minimize Full" -- description might be wrong... fd = checkDescr focusDown (windows W.focusDown) "Minimize Full"
checkDescr :: X () -> X () -> String -> X () checkDescr regular exception exceptionLayout = do descr <- gets $ description . W.layout . W.workspace . W.current . windowset if descr == exceptionLayout then exception else regular
Of course, this is a pretty fragile solution since changing layout modifiers can change the layout descriptions, which means you will end up with the regular boringAuto behavior. Perhaps more reliable would be to compare on the last word of the layout description:
checkDescr2 :: X () -> X () -> String -> X () checkDescr2 regular exception exceptionLayout = do descr <- gets $ description . W.layout . W.workspace . W.current . windowset let (~=) = (==) `on` (listToMaybe . reverse . words) if descr ~= exceptionLayout then exception else regular
And then regardless of which auxiliary function you use (checkDescr2, or checkDescr), you can bind the fu and fd actions as you did the regular focusUp and focusDown actions. If you have trouble for imports, you need at least these ones for checkDescr2:
import XMonad import qualified XMonad.StackSet as W import XMonad.Layout.BoringWindows import Data.Function (on) import Data.Maybe (listToMaybe)
-- Adam Vogt
Am Samstag, den 19.12.2009, 10:59 -0500 schrieb Adam Vogt:
* On Saturday, December 19 2009, Ralph Hofmann wrote:
Hi
I am new to xmonad. I use version 0.9.
I am trying to get "minimize" and "boringAuto" working together, like described here: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Minimize.html ... Everythings works fine, except the Full-mode. In Full-mode the functions focusUp and focusDown from XMonad.Layout.BoringWindows don't switch to the next or previous window. They do nothing.
I would like to be able to cycle in Full-mode through all windows but the minimized windows. Is there anything, I can do?
Ralph
In the case of Full, boringAuto is doing exactly as it is supposed to do. I'm not sure that adding a special case to it makes sense to address this situation; that would be more surprising behavior; lets say you minimize all windows except one, should boringAuto now let you focus between windows?
If all windows except one are minimized, "my" boringAuto would behave exactly like the built in: it would skip the minimized windows and show only the one not minimized. It's probably hard to define which behavour is expected and which is surprising, but I think a generel rule could be: the Full-mode should follow the same logic of focusing as the tiled mode; unless there is a strong reason against it. Is there any reason like that? So in my understanding not "my" boringAuto is the "special case", but the built in.
Then again, maybe such a thing should be made an option, since that change would be much cleaner and reliable than the following hack based on checking your layout description, and then decide to send whichever message you want based on that:
fu,fd :: X () fu = checkDescr focusUp (windows W.focusUp) "Minimize Full" -- description might be wrong... fd = checkDescr focusDown (windows W.focusDown) "Minimize Full"
checkDescr :: X () -> X () -> String -> X () checkDescr regular exception exceptionLayout = do descr <- gets $ description . W.layout . W.workspace . W.current . windowset if descr == exceptionLayout then exception else regular
Of course, this is a pretty fragile solution since changing layout modifiers can change the layout descriptions, which means you will end up with the regular boringAuto behavior.
Perhaps more reliable would be to compare on the last word of the layout description:
checkDescr2 :: X () -> X () -> String -> X () checkDescr2 regular exception exceptionLayout = do descr <- gets $ description . W.layout . W.workspace . W.current . windowset let (~=) = (==) `on` (listToMaybe . reverse . words) if descr ~= exceptionLayout then exception else regular
And then regardless of which auxiliary function you use (checkDescr2, or checkDescr), you can bind the fu and fd actions as you did the regular focusUp and focusDown actions.
If you have trouble for imports, you need at least these ones for checkDescr2:
import XMonad import qualified XMonad.StackSet as W import XMonad.Layout.BoringWindows import Data.Function (on) import Data.Maybe (listToMaybe)
-- Adam Vogt
Thank you for showing me alternatives. I will have to review some haskell tutorial before going on;-) Ralph
* On Saturday, December 19 2009, Ralph Hofmann wrote:
Am Samstag, den 19.12.2009, 10:59 -0500 schrieb Adam Vogt: ...
In the case of Full, boringAuto is doing exactly as it is supposed to do. I'm not sure that adding a special case to it makes sense to address this situation; that would be more surprising behavior; lets say you minimize all windows except one, should boringAuto now let you focus between windows?
If all windows except one are minimized, "my" boringAuto would behave exactly like the built in: it would skip the minimized windows and show only the one not minimized.
It's probably hard to define which behavour is expected and which is surprising, but I think a generel rule could be: the Full-mode should follow the same logic of focusing as the tiled mode; unless there is a strong reason against it. Is there any reason like that?
So in my understanding not "my" boringAuto is the "special case", but the built in.
Oh, now I understand that you want a distinction made between non-visible windows, and windows that are minimized. The boringAuto modifier doesn't catch this because Full lays out the windows such that all of them will be recognized as boring by boringAuto, before the minimizing modifier has a chance to remove them. main> pureLayout Full (Rectangle 0 0 0 0) (W.Stack 0 [1,2,3] [4,5,6]) [(0,Rectangle {rect_x = 0, rect_y = 0, rect_width = 0, rect_height = 0})] Compare with what XMonad.Layout.Simplest.Simplest which differs from full only in that it won't signal to boringAuto that all unfocused windows are boring: main> pureLayout Simplest (Rectangle 0 0 0 0) (W.Stack 0 [1] [2]) [(1, Rectangle{rect_x = 0, rect_y = 0, rect_width = 0, rect_height = 0}), (0, Rectangle{rect_x = 0, rect_y = 0, rect_width = 0, rect_height = 0}), (2, Rectangle{rect_x = 0, rect_y = 0, rect_width = 0, rect_height = 0})]
...
Thank you for showing me alternatives. I will have to review some haskell tutorial before going on;-)
You could just copy-paste that code anywhere in your config after the imports and use the fu and fd actions as if they were defined in some extension module. But on further reading, I think that using Simplest instead of Full is closer to what you ask than that code (which basically disregards minimized windows when using Full). -- Adam
On Sat, Dec 19, 2009 at 05:53:43PM -0500, Adam Vogt wrote:
* On Saturday, December 19 2009, Ralph Hofmann wrote:
If all windows except one are minimized, "my" boringAuto would behave exactly like the built in: it would skip the minimized windows and show only the one not minimized.
Oh, now I understand that you want a distinction made between non-visible windows, and windows that are minimized.
As the author of X.L.Minimize, I would consider the behaviour that Ralph pointed out to be a bug, so thx Ralph for bringing it up! To be clear, boringAuto works as it should, but I need to find another approach then to make it work better with the Full-layout. When I looked into focus skipping for minimized windows, I was lazy and just used boringAuto, because I figured every minimized window has no rectangle associated with it, so would be marked by boringAuto. I didn't think of cases, where a window has no rectangle associated with it, but isn't minimized - as in the case of the Full-layout. So I think the proper way to fix this is to have X.L.Minimize explicitly export the list of currently minimized windows as 'boring' and stop using boringAuto. That should yield the behaviour that Ralph is looking for, namely have the focus only skip windows that are actually in the state 'minimized' independent of whether they are currently visible or not. I think that is what one would expect. I will write up a patch some time soon for that. In the meantime you - Ralph - will need to use one of the workarounds Adam mentioned. To use XMonad.Layout.Simplest instead of Full seems like a good workaround, if it indeed stops boringAuto from marking non-visible but also non-minimized windows as boring. Unfortunately, in my tests I still can't change the focus to them (?). Regards, Jan
* On Sunday, December 20 2009, Jan Vornberger wrote:
I will write up a patch some time soon for that. In the meantime you - Ralph - will need to use one of the workarounds Adam mentioned. To use XMonad.Layout.Simplest instead of Full seems like a good workaround, if it indeed stops boringAuto from marking non-visible but also non-minimized windows as boring. Unfortunately, in my tests I still can't change the focus to them (?).
Regards,
Jan
Hello Jan, Which order did you compose boringAuto and minimize? I just tried it, and the only order that works is:
layoutHook = boringAuto $ minimize Simplest -- though I really used onWorkspace too, this is the same thing.
This makes sense, since boringAuto needs to be able to see which windows are removed by minimize. I'm not sure that it is necessary to code anything as a workaround. You could use the feature in BoringWindows which accepts messages to mark specific windows as boring. -- Adam
Hi! On Sun, Dec 20, 2009 at 12:13:00PM -0500, Adam Vogt wrote:
Which order did you compose boringAuto and minimize? I just tried it, and the only order that works is:
layoutHook = boringAuto $ minimize Simplest -- though I really used onWorkspace too, this is the same thing.
This makes sense, since boringAuto needs to be able to see which windows are removed by minimize.
That's the order in which I have it as well. I just realized, why it didn't work. I also have a decoration in the mix, which - if I recall the code correctly - removes windows that are exactly stacked on top of each other. If I do it without the decoration it works!
I'm not sure that it is necessary to code anything as a workaround. You could use the feature in BoringWindows which accepts messages to mark specific windows as boring.
That's what I was thinking, write a patch that will make X.L.Minimize send out messages to mark all minimized windows as boring. That should be a more reliable way than using boringAuto. Regards, Jan
On Mon, Dec 21, 2009 at 12:51:09AM +0100, Jan Vornberger wrote:
On Sun, Dec 20, 2009 at 12:13:00PM -0500, Adam Vogt wrote:
I'm not sure that it is necessary to code anything as a workaround. You could use the feature in BoringWindows which accepts messages to mark specific windows as boring.
That's what I was thinking, write a patch that will make X.L.Minimize send out messages to mark all minimized windows as boring. That should be a more reliable way than using boringAuto.
Or are you saying, you don't think any change of X.L.Minimize is necessary and one could just do it all in the configuration with the functions that BoringWindows exports? I guess so, but I feel focus skipping of minimized windows is an integral part of X.L.Minimize, so the module might as well do the work itself of making sure the correct windows are marked as boring. Cheers! Jan
* On Monday, December 21 2009, Jan Vornberger wrote:
On Mon, Dec 21, 2009 at 12:51:09AM +0100, Jan Vornberger wrote:
On Sun, Dec 20, 2009 at 12:13:00PM -0500, Adam Vogt wrote:
I'm not sure that it is necessary to code anything as a workaround. You could use the feature in BoringWindows which accepts messages to mark specific windows as boring.
That's what I was thinking, write a patch that will make X.L.Minimize send out messages to mark all minimized windows as boring. That should be a more reliable way than using boringAuto.
Or are you saying, you don't think any change of X.L.Minimize is necessary and one could just do it all in the configuration with the functions that BoringWindows exports? I guess so, but I feel focus skipping of minimized windows is an integral part of X.L.Minimize, so the module might as well do the work itself of making sure the correct windows are marked as boring.
Cheers!
Jan
If you can't manage to compose decorations with the minimize and boringAuto modifier in a way that works correctly, then I guess you do have to change Minimize. You are likely to still end up with only one (or maybe a couple) order(s) of composition being acceptable in any case, since decorations should not be given for windows that get removed later on. -- Adam
On Mon, Dec 21, 2009 at 12:51:09AM +0100, Jan Vornberger wrote:
On Sun, Dec 20, 2009 at 12:13:00PM -0500, Adam Vogt wrote:
I'm not sure that it is necessary to code anything as a workaround. You could use the feature in BoringWindows which accepts messages to mark specific windows as boring.
That's what I was thinking, write a patch that will make X.L.Minimize send out messages to mark all minimized windows as boring. That should be a more reliable way than using boringAuto.
The current darcs version of X.L.Minimize now does this. Regards, Jan
participants (3)
-
Adam Vogt -
Jan Vornberger -
Ralph Hofmann