* 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 compatibility.

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. Cheers, Norbert

On Tue, Apr 7, 2009 at 6:03 PM, Ismael Carnales wrote:

And make XMonad more begginer friendly

If Newcomers like it

You got another user

With another point of view to contribute to the project

And get more name, jobs, etc :)

And some ranters :)

Anyway here goes some ideas that i spitted out in the xmonad channel, suggest, criticism help and such welcome

* 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 compatibility.

  Other modules could use the same approach, for ex:

  defaultShellPrompt = shellPrompt defaultXPConfig

simpleDefaultConfig

  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.

  Other configs can be based on simpleDefaultConfig providing some pre-feeded values on some hooks, usefull for statusbars i.e.: dzenStatusSimpleDefaultConfig, xmobarStatusSimpleDefaultConfig.

  Or better, simpleDefaultConfig could inherit some defaults from another Config like dzenStatusConfig, so you would pick the parts that suits you.

  This approach will give easier entry point to configs for newbies without loosing power, all normal config items would have to be available, these funcions will only provide helpers and shortcuts.

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.

So something like ShellPrompt using the GridSelect UI? Sounds like a good idea. Does anyone want to do it? -- gwern