[xmonad] Decoration rewrite

Gwern Branwen gwern0 at gmail.com
Mon Feb 13 00:18:26 CET 2012

On Sun, Feb 12, 2012 at 4:54 PM, Norbert Zeh <nzeh at cs.dal.ca> wrote:
> The reason why I'm writing about this *before* putting the effort into testing
> all my changes is that I'd like to know how the community feels about a change
> in the interface of the DecorationStyle type class.  As it is, there are only
> two choices: accept this change or continue to live with quadratic-time
> behaviour of all or at least most decoration modules because the latter is
> unavoidable with the current interface.  This change in interface should only
> affect other modules in XMonadContrib, and I've converted them to the new
> interface already.  User configurations should not be affected even for the
> majority of people who use window decorations because they will normally simply
> use the layout modifiers based on the decoration module - they will not directly
> use the DecorationStyle class.

/puts on XMC commit hat

The performance issue is a serious one, which has caused emails for
years now, and has no doubt irritated many users. I'd rank it as one
of the most serious issues with stock XMC and something that should.
If the performance really is fixed by a breaking API change, then I'm
cool with it as long as the 8 or 9 modules using DecorationStyle are
also fixed - breaking the compile or runtime is pretty non-negotiable.

User-wise, I'm not concerned. There's only one config in my copy of
the config archive which even imports XMonad.Layout.Decoration, and
that config apparently isn't even current since it doesn't show up
when I download a fresh copy*; perfectly acceptable collateral damage.

* speaking of which, the config archive downloader has been broken for
a while - I fixed it:


More information about the xmonad mailing list