[xmonad] Some ideas that could be implemented
nzeh at cs.dal.ca
Tue Apr 7 21:14:52 EDT 2009
> * Layout constructors:
> Layouts could export alongside their constructors, a constructor function
> that calls the latter with some default arguments, this allows to aliase
> more common used layouts and become friendlier with newcomers. Also is good
> that users don't invoke the "official layout constructor" from their configs
> so mantainers can change the arguments it takes without breaking
For newcomers, this would indeed be a good idea. It should, however,
be considered only an entry drug ;) My reason for this statement is
that ease of configuration usually comes at an expense of flexibility.
If you want to retain the flexibility provided by the current API, yet
provide it through hooks, I think advanced configuration will end up
being more complicated than it is now.
> A module that provides an structure to configure XMonad by editing some
> hooks, instead of hoving to build them, usefull to make some non-default
> configs default in this module, like modkey, borders, avoidstrust, more
> friendlier managehook, with hooks for floats, moveTo, etc.
Same comment as above applies, I believe.
> A GridSelect oriented program launcher:
> Inspired by "intelligent launchers" we could make an app launcher that
> shows its options arranged like a keyboard, inteligently ordered, so most
> used apps will be in the home row an continuing outside.
> Also I think that providing a "directional free" navigation to promp
> options would be good, maybe that when the prompt is showing options it
> could capture some keybinding that says, move to right, up, JKL, et. To make
> long lists more usable.
As you said yourself, xmonad's philosophy that a window manager should
manage windows, no more, is a good one. Such an app launcher, while
nice, should be kept outside xmonad and provided as a separate app a la
xmobar or dzen. The current keybinding mechanism can easily launch this
app launcher as an external app.
> Lego Layouts
> If we succed in extracting every repeated behaiviour from different layouts:
> i.e: respecting Hints, we could expand the targets that get that behaiviour,
> and also make a new way of constructing layouts by stacking a base one and
> adding modifiers, so each piece providing some Layout functionality or
> behaivour will be unique. DRY
I think this is a very good point. There are useful modules, such as
LayoutCombinators and LayoutModifiers, that can be used to build more
advanced layouts from simple ones. I found the layout combinators too
limited at this point, however. Let me illustrate this. I wrote a
layout that consists of two grids: a master and a slave. The master has
a fixed number of columns and rows, and anything that doesn't fit into
this gets shoved into the slave grid. Since there is already a grid
layout, something like this is a perfect candidate to be built from two
grid layouts using a layout combinator. I didn't see, however, how I
would be able to implement the automatic shifting of windows between the
two grids depending on the number of windows on the screen without
significant plumbing. It may of course be simply my limited
understanding of all the things that are there in xmonad contrib.
My 0.2 dimes.
More information about the xmonad