XMonad 0.5, combo layouts, swapDown and swapUp
Hey all, First up, love the new configuration method, my xmonad.hs file is now nice and tiny :-) Quick "maybe glitch" though, I'm using ComboLayout with Tabbed, and I find that when I first add lots of windows to the layout the alt-tab order is correct (also when adding windows into the middle of the stack it's correct). When I swapDown or swapUp _in_ the stack, the order is correct. But if I swapDown or swapUp at either end of the stack the ordering goes rather pearshaped (the ordering is no longer correct "visually" if you see what I mean). Is this a known thing ? My xmonad.hs is below. Cheers, Dave ---- import XMonad hiding (Tall(..)) import qualified XMonad.StackSet as W import XMonad.Layout.Tabbed import XMonad.Layout.Combo import XMonad.Layout.TwoPane import XMonad.Layout.NoBorders import XMonad.Layout.HintedTile import XMonad.Config (defaultConfig) import XMonad.Hooks.DynamicLog import XMonad.Util.Dmenu import qualified Data.Map as M import System.IO (hPutStrLn) daveConfig = defaultConfig { defaultGaps = [(0,15,0,0)] , logHook = dynamicLog , terminal = "xterm -fa Mono -fs 12" , layoutHook = smartBorders ( combineTwo (TwoPane 0.03 0.5) (tabbed shrinkText defaultTConf) (tabbed shrinkText defaultTConf) ||| mytab ||| tiled Tall ||| tiled Wide ||| Full ) , keys = \c -> mykeys c `M.union` keys defaultConfig c } where -- layouts tiled = HintedTile 1 0.03 0.5 mytab = tabbed shrinkText defaultTConf -- key mapping overrides mykeys (XConfig {modMask = modm, workspaces = ws}) = M.fromList $ [((modm, xK_Left ), sendMessage Shrink) -- %! Shrink the master area ,((modm, xK_Right ), sendMessage Expand) -- %! Expand the master area ,((modm, xK_p ), spawn "exe=`cat /home/dave/.dmenulist | dmenu -b -p \"$\"` && eval \"exec $exe\"") -- @@ Launch dmenu ] main = xmonad $ daveConfig
On Mon, Dec 10, 2007 at 05:13:02PM +1100, Dave Harrison wrote:
Quick "maybe glitch" though, I'm using ComboLayout with Tabbed, and I find that when I first add lots of windows to the layout the alt-tab order is correct (also when adding windows into the middle of the stack it's correct). When I swapDown or swapUp _in_ the stack, the order is correct. But if I swapDown or swapUp at either end of the stack the ordering goes rather pearshaped (the ordering is no longer correct "visually" if you see what I mean). Is this a known thing ? ... , layoutHook = smartBorders ( combineTwo (TwoPane 0.03 0.5) (tabbed shrinkText defaultTConf) (tabbed shrinkText defaultTConf) ||| mytab ||| tiled Tall ||| tiled Wide ||| Full )
First, let me note that you could create the same layout more elegantly as layoutHook = smartBorders ( mytab *|* mytab ||| mytab ||| tiled Tall ||| tiled Wide ||| Full ) Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax). -- David Roundy Department of Physics Oregon State University
David Roundy wrote:
On Mon, Dec 10, 2007 at 05:13:02PM +1100, Dave Harrison wrote:
Quick "maybe glitch" though, I'm using ComboLayout with Tabbed, and I find that when I first add lots of windows to the layout the alt-tab order is correct (also when adding windows into the middle of the stack it's correct). When I swapDown or swapUp _in_ the stack, the order is correct. But if I swapDown or swapUp at either end of the stack the ordering goes rather pearshaped (the ordering is no longer correct "visually" if you see what I mean). Is this a known thing ? ... , layoutHook = smartBorders ( combineTwo (TwoPane 0.03 0.5) (tabbed shrinkText defaultTConf) (tabbed shrinkText defaultTConf) ||| mytab ||| tiled Tall ||| tiled Wide ||| Full )
First, let me note that you could create the same layout more elegantly as
layoutHook = smartBorders ( mytab *|* mytab ||| mytab ||| tiled Tall ||| tiled Wide ||| Full )
Cheers David, I'll use that one ! :-)
Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax).
So just to clarify, does this mean that there IS an ugly hack in place but there is a bug in it, or the solution would be an ugly hack that has not been implemented ? Cheers D
On Tue, Dec 11, 2007 at 08:20:04AM +1100, Dave Harrison wrote:
David Roundy wrote:
Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax).
So just to clarify, does this mean that there IS an ugly hack in place but there is a bug in it, or the solution would be an ugly hack that has not been implemented ?
It means there IS an ugly hack in place, and it's got a bug because reimplementing most of xmonad core in an extension seems to me like the wrong way to go... besides the fact that it would require you to use custom shiftUp/Down etc. Xmonad is just not designed to be extensible in the way that Combo extends it, and this shows. -- David Roundy Department of Physics Oregon State University
David Roundy wrote:
On Tue, Dec 11, 2007 at 08:20:04AM +1100, Dave Harrison wrote:
David Roundy wrote:
Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax). So just to clarify, does this mean that there IS an ugly hack in place but there is a bug in it, or the solution would be an ugly hack that has not been implemented ?
It means there IS an ugly hack in place, and it's got a bug because reimplementing most of xmonad core in an extension seems to me like the wrong way to go... besides the fact that it would require you to use custom shiftUp/Down etc. Xmonad is just not designed to be extensible in the way that Combo extends it, and this shows.
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
On 2007-12-11 10:37:38 Dave Harrison wrote:
David Roundy wrote:
On Tue, Dec 11, 2007 at 08:20:04AM +1100, Dave Harrison wrote:
Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax). So just to clarify, does this mean that there IS an ugly hack in
David Roundy wrote: place but there is a bug in it, or the solution would be an ugly hack that has not been implemented ?
It means there IS an ugly hack in place, and it's got a bug because reimplementing most of xmonad core in an extension seems to me like the wrong way to go... besides the fact that it would require you to use custom shiftUp/Down etc. Xmonad is just not designed to be extensible in the way that Combo extends it, and this shows.
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
Try the WindowNavigation plugin? /J
On Tue, 2007/12/11 10:37:38 +1100, Dave Harrison wrote:
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
What about LayoutScreens? http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-LayoutScreens... I haven’t used it, but it sounds like it might suffice.
lithis wrote:
On Tue, 2007/12/11 10:37:38 +1100, Dave Harrison wrote:
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
What about LayoutScreens?
http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-LayoutScreens...
I haven’t used it, but it sounds like it might suffice.
Just started trying this one out now, looks quite useful for what I need (in fact I rather like it alot :-)). Doesn't seem to permit for resizing of the screens though (not an obvious use-case I guess hehehe).
dave:
lithis wrote:
On Tue, 2007/12/11 10:37:38 +1100, Dave Harrison wrote:
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
What about LayoutScreens?
http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-LayoutScreens...
I haven’t used it, but it sounds like it might suffice.
Just started trying this one out now, looks quite useful for what I need (in fact I rather like it alot :-)). Doesn't seem to permit for resizing of the screens though (not an obvious use-case I guess hehehe).
Did you find a satisfactory solution to this, Dave? -- Don
On Tue, Dec 11, 2007 at 10:37:38AM +1100, Dave Harrison wrote:
David Roundy wrote:
On Tue, Dec 11, 2007 at 08:20:04AM +1100, Dave Harrison wrote:
David Roundy wrote:
Secondly, with regard to focus order, Combo separates the focus order from the visual representation, because the focus order is handled by core xmonad, which has no knowledge of the hierarchical grouping, and isn't friendly to layouts reordering windows. A proper fix would be to implement hierarchical Stacks in the core, but that seems unlikely, so we are left with ugly hacks, and ugly hacks are likely to remain ugly (although, we *can* give them beautiful syntax). So just to clarify, does this mean that there IS an ugly hack in place but there is a bug in it, or the solution would be an ugly hack that has not been implemented ?
It means there IS an ugly hack in place, and it's got a bug because reimplementing most of xmonad core in an extension seems to me like the wrong way to go... besides the fact that it would require you to use custom shiftUp/Down etc. Xmonad is just not designed to be extensible in the way that Combo extends it, and this shows.
Yow, that's a bit of a showstopper for me since I'm a heavy user of ComboLayout at the office (dev on a big monitor calls for a Full to the left and tabs to the right I find) - I'm suddenly considering a downgrade :-( What's the way forward here ?
What's the problem with combineTwo (or LayoutCombinators)? (Other than that they're undocumented...) -- David Roundy Department of Physics Oregon State University
participants (5)
-
Dave Harrison -
David Roundy -
Don Stewart -
Jamie Webb -
lithis