[xmonad] Decoration rewrite
nzeh at cs.dal.ca
Mon Feb 13 04:08:15 CET 2012
wagnerdm at seas.upenn.edu [2012.02.12 2017 -0500]:
> Quoting Norbert Zeh <nzeh at cs.dal.ca>:
> >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
> Is this interface one which is likely to be used in user configs?
> That is, after you make the necessary changes to XMC code, do you
> think it's likely users will also have to update their configs in
> the same way? Or are the most public APIs the same?
Users will only be affected if they write their own instance of the
DecorationStyle class and use it in their xmonad.hs. If they use any of the
standard layout modifiers, such as TabBarDecoration, NoFrillsDecoration, and the
likes, they won't notice any change.
Alas, this is more literally true than I hoped. Upon closer comparison of the
two versions of Decoration.hs, I currently see hardly any performance
difference, which is odd because, at least for 30ish windows, there should be
about a factor 5-6 difference in speed. I suspect that I'm doing way too many
conversions back and forth between different representations of the stack and
the window-rectangle mapping returned by the underlying layout. I have a number
of ideas how to avoid these conversions and avoid lookups in many places, but
implementing all these tweaks will take time.
In any case, no matter what I end up doing with Decoration.hs, one of my top
priorities is to ensure that the above remains true. After all, since I started
using xmonad, part of its appeal has always been its stable API.
More information about the xmonad