how amenable to making xmonad less minimalistic?

Hi all, I've just gotten xmonad running (in a separate X server, for simplicity), and it looks like a nice start, and the code looks pretty elegant, but I'm wondering how amenable it's going to be to added complexity? I'm a current ion3 user who's mostly content, but a bit frustrated by its limitations, and the complexity of configuring it using lua. On the other hand, I've also gotten my setup working pretty much as I like now, so it's not really worthwhile to switch. The features I most like in ion3 that are missing in xmonad are the (very crude) ability to configure the layout based on the windows themselves and the tabs. And what I *really* like (which took a fair amount of sweat and pain) is the ability to set up a single command that prompts me for a directory, and then creates a new workspace with the layout I want, and in it launches several programs (typically an emacs, a couple of terminals and an xclock, but only one terminal on my laptop), with the chosen directory set as the working directory for each program, and any future programs launched in that workspace also has the same working directory. All of this would be much easier to code in Haskell, provided the framework is there. So I'm just wondering if there will be hooks to provide some of this. LayoutDesc, for example, seems to be written in a sufficiently minimalistic way that adding a new layout would seem somewhat like surgery. I imagine we could have a design something like data LayoutDesc = LayoutDesc { !layout :: Rectangle -> [Window] -> [(Window, Rectangle)] } which would have the advantage of allowing commands to introduce arbitrary bindings. The catch is that we've lost the ability to tune the tileFraction, so I've not come up with a real solution. But I'd like to be able to play with new layouts without hacking directly in Operations.hs, and we really shouldn't need to add new parameters to LayoutDesc for every degree of freedom we might want to give our layout. i.e. there's got to be a better way! My first goal (but not most important) would be to ensure that my xclocks always remain square. This would avoid much of the insanity that comes with the current inflexible layout of xmonad (i.e. either the xclock takes up much of the screen and is very distorted, or all but one of my windows is a small square of wasted space). -- David Roundy http://www.darcs.net

droundy:
Hi all,
I've just gotten xmonad running (in a separate X server, for simplicity), and it looks like a nice start, and the code looks pretty elegant, but I'm wondering how amenable it's going to be to added complexity?
I'm a current ion3 user who's mostly content, but a bit frustrated by its limitations, and the complexity of configuring it using lua. On the other hand, I've also gotten my setup working pretty much as I like now, so it's not really worthwhile to switch.
The features I most like in ion3 that are missing in xmonad are the (very crude) ability to configure the layout based on the windows themselves and the tabs. And what I *really* like (which took a fair amount of sweat and pain) is the ability to set up a single command that prompts me for a directory, and then creates a new workspace with the layout I want, and in it launches several programs (typically an emacs, a couple of terminals and an xclock, but only one terminal on my laptop), with the chosen directory set as the working directory for each program, and any future programs launched in that workspace also has the same working directory.
Wow. That sounds complex/fun :-)
All of this would be much easier to code in Haskell, provided the framework is there. So I'm just wondering if there will be hooks to provide some of
Right. I think this is probably how we proceed. xmonad acts as a super-clean, EDSL-ish dwm clone, with a proper api exposed for arbtirary extensions. Then we get both a simple, minimal core. And users can add arbtirarily bloat^h^h^h^hclever extensions ;-)
this. LayoutDesc, for example, seems to be written in a sufficiently minimalistic way that adding a new layout would seem somewhat like surgery. I imagine we could have a design something like
data LayoutDesc = LayoutDesc { !layout :: Rectangle -> [Window] -> [(Window, Rectangle)] }
which would have the advantage of allowing commands to introduce arbitrary bindings. The catch is that we've lost the ability to tune the tileFraction, so I've not come up with a real solution. But I'd like to be able to play with new layouts without hacking directly in Operations.hs,
Yes. I think this is a goal: users should not need to modify Operations.hs, they should just be EDSL stuff, and default dwm bindings.
and we really shouldn't need to add new parameters to LayoutDesc for every degree of freedom we might want to give our layout. i.e. there's got to be a better way!
My first goal (but not most important) would be to ensure that my xclocks always remain square. This would avoid much of the insanity that comes with the current inflexible layout of xmonad (i.e. either the xclock takes up much of the screen and is very distorted, or all but one of my windows is a small square of wasted space).
Ok. First goal is to try to add a layout purely in Config.hs I think. That'll tell us what needs to be exposed. -- Don
participants (2)
-
David Roundy
-
dons@cse.unsw.edu.au