On Sun, Feb 12, 2012 at 4:54 PM, Norbert Zeh
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: http://www.haskell.org/haskellwiki/index.php?title=Xmonad%2FConfig_archive&diff=44498&oldid=44384 -- gwern http://www.gwern.net