need help with Tabbed

Hello, Is there any way to move focus to the next/previous tab in the Tabbed layout, preferably wrapping around the sides? focusUp and focusDown seem to switch tabs in some random order. If no - could you give me some hints on how to implement it please.

* On Tuesday, April 07 2009, Konstantin Sobolev wrote:
Hello,
Is there any way to move focus to the next/previous tab in the Tabbed layout, preferably wrapping around the sides? focusUp and focusDown seem to switch tabs in some random order.
If no - could you give me some hints on how to implement it please.
By focusUp and focusDown, you mean?:
windows W.focusUp windows W.focusDown
Or Layout.BoringWindows.focusUp ? <-- this one rearranged the stack strangely, but I changed it. subTabbed in SubLayouts has it right for the use of multiple stacks of tabbed windows (or you're not after this?), but the solution is definitely not the simplest one. Repo here, since pointing at patch bundles is a bit awkward: darcs get --partial http://www.eng.uwaterloo.ca/~aavogt/XMonadContrib Thanks, Adam

On Tue, Apr 7, 2009 at 10:28 PM, Adam Vogt
* On Tuesday, April 07 2009, Konstantin Sobolev wrote:
Is there any way to move focus to the next/previous tab in the Tabbed layout, preferably wrapping around the sides? focusUp and focusDown seem to switch tabs in some random order.
If no - could you give me some hints on how to implement it please.
By focusUp and focusDown, you mean?:
windows W.focusUp windows W.focusDown
yes
subTabbed in SubLayouts has it right for the use of multiple stacks of tabbed windows (or you're not after this?), but the solution is definitely not the simplest one.
yes, probably that's it. I should've stated it more clearly. Wirt is right, just Tabbed works fine. But, for instance, simpleTabbed *|* simpleTabbed makes the focus jump between the panes, which of course is caused by single stack behind it. One more reason in my case is a just discovered bug in my ComboP - it disregards the order of windows in the stack passed to doLayout.
Repo here, since pointing at patch bundles is a bit awkward:
darcs get --partial http://www.eng.uwaterloo.ca/~aavogt/XMonadContrib
Thanks, will take a look

The url to the repo is dead :(
On Tue, Apr 7, 2009 at 11:28 PM, Adam Vogt
* On Tuesday, April 07 2009, Konstantin Sobolev wrote:
Hello,
Is there any way to move focus to the next/previous tab in the Tabbed layout, preferably wrapping around the sides? focusUp and focusDown seem to switch tabs in some random order.
If no - could you give me some hints on how to implement it please.
By focusUp and focusDown, you mean?:
windows W.focusUp windows W.focusDown
Or Layout.BoringWindows.focusUp ? <-- this one rearranged the stack strangely, but I changed it.
subTabbed in SubLayouts has it right for the use of multiple stacks of tabbed windows (or you're not after this?), but the solution is definitely not the simplest one.
Repo here, since pointing at patch bundles is a bit awkward:
darcs get --partial http://www.eng.uwaterloo.ca/~aavogt/XMonadContribhttp://www.eng.uwaterloo.ca/%7Eaavogt/XMonadContrib
Thanks, Adam _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

On Tue, Apr 7, 2009 at 10:28 PM, Adam Vogt
subTabbed in SubLayouts has it right for the use of multiple stacks of tabbed windows (or you're not after this?), but the solution is definitely not the simplest one.
I've finally implemented it as a layout modifier that cycles windows in it's sublayout. Wrapping Tabbed gives me desired behavior. I've now ported almost all the of the Ion features I was used to :) Only some named scratchpads stuff left: I want to combine them with runOrRaise BTW, guys, should I send things like this here or I'm just wasting your time and traffic?

Excerpts from Konstantin Sobolev's message of Wed Apr 08 22:48:06 -0600 2009:
I've now ported almost all the of the Ion features I was used to :) Only some named scratchpads stuff left: I want to combine them with runOrRaise
Neat stuff! Many people will appreciate these contribs, I think.
BTW, guys, should I send things like this here or I'm just wasting your time and traffic?
The best is to send contributions as darcs patches. byorgey has written a great development tutorial about how to do so: http://haskell.org/haskellwiki/Xmonad/xmonad_development_tutorial If you have a mail agent set up, 'darcs send' is a little better than manually attaching patches, since that way they automatically get tracked by darcswatch [1] and are (I think) somewhat easier to commit. But generating a dpatch and attaching to an email to this list is fine. [1] http://darcswatch.nomeata.de -- wmw

I find it interesting to compare solutions to problems I've looked at. Hopefully my suggestions are somewhat useful. I think that this can be simplified by using more functions from XMonad.StackSet, and keeping the Maybe (W.Stack a) as it is from the pureModifier.
W.focusWindow (W.focus $ W.focusUp' ws)
rather than:
W.modify' (cycl W.focusUp' ws)
Since the cycl function could be a point of failure since it isn't as well tested as those in XMonad.StackSet, and also because I don't understand it :) If you allow the message contain a function, I think that it could simplify things and allow more options without having to touch the CycleFocus instance.
data OnWindowSubset a = OnWindowSubset (W.Stack a -> W.Stack a) deriving (Read, Show, Typeable) instance Typeable a => Message (OnWindowSubset a)
focusNth n = sendMessage $ OnWindowSubset $ \w -> iterate W.focusDown' (focusMaster' w) !! mod n (len w) where focusMaster' = fromJust . W.differentiate . W.integrate len = length . W.integrate
-- Adam

On Thu, Apr 9, 2009 at 2:13 AM, Adam Vogt
I find it interesting to compare solutions to problems I've looked at. Hopefully my suggestions are somewhat useful.
Of course!
I think that this can be simplified by using more functions from XMonad.StackSet, and keeping the Maybe (W.Stack a) as it is from the pureModifier.
W.focusWindow (W.focus $ W.focusUp' ws)
rather than:
W.modify' (cycl W.focusUp' ws)
Since the cycl function could be a point of failure since it isn't as well tested as those in XMonad.StackSet, and also because I don't understand it :)
My intention was to allow cycling focus with wrapping around the 'corners' - something that can't be achieved by mere focusWindow I think. cycl keeps applying specified function (focusUp' or focusDown' in my case) until focused window shows up among the windows managed by sublayout.
If you allow the message contain a function, I think that it could simplify things and allow more options without having to touch the CycleFocus instance.
Yeah.. this idea gives so much power that it's almost an overkill for my simple needs :) It also looks like reimplementing some parts of SubLayouts.
data OnWindowSubset a = OnWindowSubset (W.Stack a -> W.Stack a) deriving (Read, Show, Typeable) instance Typeable a => Message (OnWindowSubset a)
I've implemented this thing out of curiosity, it even works:
,((myMod, xK_Right), sendMessage $ ModifyWindowSubset (W.focusDown'::(Stack Window -> Stack Window))) ,((myMod, xK_Left), sendMessage $ ModifyWindowSubset (W.focusUp'::(Stack Window -> Stack Window)))
(BTW: I don't know how to get rid of this type annotation both here and in the handleMess, see the source. GHC says Ambiguous type variable `t' in the constraint: `Typeable t' if I remove it. May be the message should be defined like
data ModifyWindowSubset = ModifyWindowSubset (W.Stack Window -> W.Stack Window) from the start? )
What confuses me is if it's really allowed to do arbitrary stack modifications from handleMess: function that we pass in the message can not only change focus, but it can rearrange the windows, or even remove them.

Excerpts from Konstantin Sobolev's message of Tue Apr 07 19:20:50 -0600 2009:
Is there any way to move focus to the next/previous tab in the Tabbed layout, preferably wrapping around the sides? focusUp and focusDown seem to switch tabs in some random order.
Hmm, I seldom use tabbed so am reluctant to answer, but that is exactly how focusUp/Down work here, at least with the simpleTabbed and withIM simpleTabbed in my current (darcs) config. Are you using some sort of combined layout? I'd imagine there can need to be special navigation methods (as in Adam's work) to "filter" the stack in such a case, since grouped windows might not be next to one another in the workspace stack. -- wmw
participants (4)
-
Adam Vogt
-
Ismael Carnales
-
Konstantin Sobolev
-
Wirt Wolff