On 1 November 2011 00:07, lolilolicon <loliloli...@gmail.com> wrote: > Indeed mfact and nmaster being members of Layout does make more sense, and > I made a patch which includes this change. > > Note that this may seem to add some SLOCs, but it actually reduces the > amount of code required to implement the same layouts by avoiding code > duplication. See how tile, bstack and col are each defined using just a > one-liner. By defining two layout algorithms `lt_vstack` and `lt_hstack`, > in combination with the hsplit switch, one can define 2 ** 2 * 2 = 8 such > layouts, and if you count the (masters|slaves)-only layouts as separate > ones, we got 10. Add a third layout algorithm, and you have > 3 ** 2 * 2 + 3 = 21. Sure, not all layouts are useful for everyone, but > hopefully this will produce some interesting layouts suitable for your > particular setup.
Thanks for you patch, I looked at it and it is indeed interesting. However it needs further testing and review in order to be a candidate for mainline at some point. Some remarks: The change of the Layout struct makes it a lot harder to define layouts, as now one also has to understand the variables nmaster/mfact. Also nmaster/mfact are now layout specific variables that might not be used by other layouts. This lacks a bit conceptual clarity imho. What I'd really prefer is keeping the interface intact we had, a layout is just a function -- I have no objections that this function calls other functions or set up some variables to fit its needs. This would keep it equally simple to the user to define Layouts and leave the interface to be a function, rather than a function + variables. Also I'm not absolutely happy about the introduction of the Booth struct, I would rename that into Rect as we have used a similar name in other areas. Having said this, I'm in favor of *not* using XRectangle where possible, in order to keep the core code of dwm X agnostic (which is one 6.0 goal btw). Cheers, Anselm
