On 1 November 2011 16:27, lolilolicon <loliloli...@gmail.com> wrote: > On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe <garb...@gmail.com> wrote: >> 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. > > I also agree with what you said here, but let me clarify my intention. > I really think it more useful to make mfact/nmaster layout-specific, > otherwise I wounldn't have made the change to the Layout struct. For > example, on my 1280x800 screen, mfact == 0.75 combined with nmaster == 2 > in the n?col layout makes a nice layout, but the combination is very > bad for the tile layout. As such, sharing mfact/nmaster across layouts > isn't exactly nice, nor is it "dynamic" enough. > > But now I realize another problem with moving mfact/nmaster to Layout. > The issue is two monitors should be able to use different mfact/nmaster > values for the same layout; also, the setmfact/incnmaster functions > will not update the unselected monitor, but will have their effects all > of a sudden next time that monitor is arranged. > This makes me want to make nmaster/mfact specific to the monitor *and* > the layout. And I also prefer achieving this in the least intrusive > way possible.
Exactly this is the main problem. You could work around it with changing monitor as follows: struct Monitor { char ltsymbol[16]; - float mfact; - int nmaster; + float mfact[LENGTH(layouts)]; + int nmaster[LENGTH(layouts)]; int num; int by; /* bar geometry */ int mx, my, mw, mh; /* screen size */ however this would require some reshuffling of the config.h inclusion and also changes in various places. So I doubt it would be necessary at all. Just stick with nmaster/mfact in Monitor. >> 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. > > You are absolutely right. Now that I think of it, we can temporarily > set m->mfact and/or m->nmaster in a layout function before calling > apply_mslts, and restore the values afterwards. For example, define > the col layout like this: > > /* int term_width is the width of a terminal (e.g. 80 characters) */ > void > col(Monitor *m) { > float mfact = m->mfact; > int nmaster = m->nmaster; > /* masters will be term_width wide */ > m->nmaster = MIN(nmaster, m->ww / term_width); > m->mfact = (float)term_width * m->nmaster / m->ww; > apply_mslts(m, False, lt_hstack, lt_vstack); > m->mfact = mfact; > m->nmaster = nmaster; > } > > A bit back-and-forth with the mfact calculation (since we will calculate > back to the width in apply_mslts), but it's a fair compromise, I guess. This could work for a patch, but I don't think this is a great way of programming for mainline, since manipulating and restoring nmaster/mfact for the time being is quite ugly. ;) Cheers, Anselm