[Xmonad] the future of xmonad...

Donald Bruce Stewart dons at cse.unsw.edu.au
Sat Jun 9 23:21:09 EDT 2007

> Hi Andrea,
> You aren't the only refugee from ion3 here.  There's me and at least one

For what its worth, I used ion for about 3 years, wmii for 6 months, dwm
for 6 months, and xmonad for the last 3.

> more (whose name escapes me).  But almost all of us have no X experience.

Quite tuue.

> I've been hacking xmonad a bit, but really shouldn't be.  This morning I
> was seeing about starting in on a tabbed layout.  The trouble I'm running
> into is that xmonad currently has no code that involves drawing to the
> screen, so there's no examples to modify! The other trouble is that it
> seems like we'd need quite a bit of infrastructure to support drawing on

Hmm yes, so contrib modules that do decorations -- we'd need to work out
how to do that. The best place to start woudl be to look at ion or wmii,
I suspect, to find out the X calls to make, and transliterate t code.

> the screen.  At a minimum I think we'd need a layout to be able to create
> "tab" windows and clean them up later, which will mean that the layout
> needs to be notified when you switch layouts so it can delete the tabs, or
> at least hide them.  And some way to define redraw functions would be
> needed as well.  :(

Hmm. yes.

> The core xmonad developers (which doesn't include me) aren't (so far as I
> can tell) ion3 refugees, and don't have the same desired features.  But

Well, I think we're all ion refugees (?), though having wandered over to
wmii/dwm for a while.

> they do seem quite friendly to the idea of making xmonad extensible, and
> for anything that can be done in XMonadContrib, we seem to be totally
> open.

Definitely. Having a single, centralised library of extensions will
likely be instrumental in helping build up the user community.

> I'm also keen on hs-plugins support.  In principle, it's not considered
> objectionable, so far as I can tell, but dons thinks hs-plugins is too
> heavyweight for xmonad (paraphrasing from memory).

Right. And we get the same functionality with state serialisation
anyway. *But* nothing's to stop people from doing a module loader as a
contrib extension!

> I'd say that xmonad source is pretty darn easy to modify, and small enough
> that it doesn't require haddock.  But I also doubt haddock patches would
> be rejected.

And its haddockised, just not generated as such, yet.

-- Don

More information about the Xmonad mailing list