The intention of supertile is to _replace_ tile. So there must only be a change in config.mk (s/tile/supertile/) and in config.h (s/tile/supertile/) - that's it already. There might be more extension points in the keys definitions of course.
Regards, Anselm On Fri, Sep 14, 2007 at 05:46:27PM +0100, Chris Webb wrote: > Kai Grossjohann <[EMAIL PROTECTED]> writes: > > > I wonder whether it would be good to make this a new layout. arg keeps > > suggesting the name "supertile", which I think very well applies to your > > layout. > > > > That might make future maintenance easier. > > I did think of doing this, but in the end I decided that it's most > logically treated as a generalisation of the existing tile layout. Since > you get identical behaviour to tile() if you set nrows=0 or ncols=1 with > nmaster=1, I couldn't see an obvious benefit in having a supertile in > addition rather than replacing tile. I could easily be convinced, though. > > My current use pattern is just with the supertile layout, but different > values for nmaster and nrows on different master tags using my 'per tag' > changes. Without the 'per tag' behaviour, I guess the ability to flip > quickly between a column stack and a standard stack on the right hand > side (without resetting the nrows/ncols state for when you return) would > be more important. > > > It would be very useful to have this on suckless.org. > > I'm happy for both of these patches to go on the contrib/patches page. > > Would anyone be interested in Xft support for the bar? It looks like it's > pretty straightforward call mapping from core text to (basic) Xft so > should be pretty trivial. > > Cheers, > > Chris. > -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
