Hi!

...

I'm currently a user of larswm; I configured it to have one large main (master) area and all the other windows of the current workspace stacked on the right site. With that configuration I am very fast selecting the window I want and making it the 'master'. I never work in one of the windows on the right site (you could also work in fullscreen mode -I hear you say- but for me its much more convenient to know in ONE look how many times I have to hit the 'next window' key than checking it every time I switch fullscreen); this means that these windows are never resized (just once when they are created at the main area).

So that's not a tiling layout, right? Could you provide a screenshot?

Hm, yes, guess you're right - I think I kind of 'misuse' the tiling for just having a method for fast selection of windows ... :-} It looks exactly like when using myLayout = HintedTile 1 0.1 0.8 XMonad.Layout.HintedTile.Tall

...

2. I could use the Tabbed Layout. Unfortunately the tabs currently are not giving me a really fast glue what is behind them. I have to read the title of the tabs - thats not very fast. I can image that some color-coding (ie. using regexps in the config) could improve this significantly. Also -since working on the terminal means looking at the bottom of the screen most of the time- putting the tabs at the bottom instead of the top would also be a great enhancement. What do you think?

This is quite simple. I don't know if it's already implemented, if not, I'll do it in the evening.

:-))) Wow, coool, thanks alot! :-)

I want to execute

...

"windows W.focusDown" followed by a "windows W.swapMaster"; I have no idea how to specify this:

((modMask .|. shiftMask, xK_Return), ... ??? ... -- windows W.focusDown && windows W.swapMaster

Use >> to sequence actions. E.g. windows W.focusDown >> windows W.swapMaster

I _knew_ this must be easy ... thanks alot! :-) - john

Hi!

...

...

...

this significantly. Also -since working on the terminal means looking at the bottom of the screen most of the time- putting the tabs at the bottom instead of the top would also be a great enhancement. What do you think? [...] Done. Update and rebuild your XMonadContrib, change tabbed to tabbedBottom and enjoy :)

Cool, works nice, thanks! :-) What do you think about coloring the tabs according to a matching title regexp? So one could give tabs containing a terminal a different color than ie. tabs containing emacs frames, etc. Thanks again! - john

* Roman Cheplyaka [2008-03-01 07:00:25+0200]

* john spencer [2008-02-29 22:43:25+0100]

...

Cool, works nice, thanks! :-) What do you think about coloring the tabs according to a matching title regexp? So one could give tabs containing a terminal a different color than ie. tabs containing emacs frames, etc.

It's not hard to add to decoration Theme a function field (Window->X (Maybe String)) which would return desired tab color, but this is an ad-hoc solution.

Besides it's unclear what to do with such things as inactiveColor or urgentColor, or border colors. Should they all be functions? Or treat them as defaults, if function above returns Nothing?

Better solution I can think of is splitting Theme into the two structures and introduce typeclass for decorations. Then we could implement colorful decorations as a different decoration, but share all the code which manages decorations. Such class (as far as I see) will contain only one method, updateDeco.

Latter solution also seems useful in long term, as somebody once could want decorations with some icons or buttons or something else.

What do you guys (esp. Andrea) think?

PS I just realized that theme anyway won't be able to contain functions, as they don't belong Show. Hm.

Here's possible solution: to push EDSL I defined in IM layout to a separate module and use classname and other props instead of regexps (must be sufficient in most cases). Still I wait for the comments about new typeclass for decorations. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

Hi!

...

...

I want to execute "windows W.focusDown" followed by a "windows W.swapMaster"; Does DwmPromote do what you want? See http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-DwmPromote.h... Exactly - thanks! :-)

Well - one thing I'd like to change: Instead of swapping I'd like to put the current master on top of the stack; ie. I have the following layout (tiled): +-----+---+ | | B | | +---+ | A | C | | +---+ | | D | +-----+---+ Now I'd like to go to 'C', press a key to move 'C' to the master area and put 'A' on TOP of the stack instead of putting it where 'C' was before: +-----+---+ | | A | | +---+ | C | B | | +---+ | | D | +-----+---+ So the next time I use DwmPromote directly, I would directly get A (instead of B). I had a look at the DwmPromote code - for a Haskell programmer I guess this is really easy ... Or is there already a functionality I didn't find so far? I found ie. XMonad.Actions.RotSlaves - this goes into the right direction but doesn't really do what I want ... Thanks! - john

Hi!

larswm has an option called tile_resize: when a window with that option is shown elsewhere with different dimensions, the underlying application does not receive an X resize event. Instead, larswm just shows the top-left part of the window, as much as fits into the "viewport" on the screen.

[...]

I think that such a 'viewport' function could be useful in xmonad as well, in some form or shape. It saves window resizes, which saves CPU and makes xterm etc. useable. Or is there already some other feature in xmonad(-contrib) to do something like this?

Ohhh, this would be GREAT. This would make xmonad the PERFECT replacement for larswm - having better support for status bar (dzen) and better handling of floating windows ... (I get really excited about the possibilities ...) ... - john