On 1 November 2011 17:04, lolilolicon <loliloli...@gmail.com> wrote:
> On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe <garb...@gmail.com> wrote:
>> 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.
>>
>
> Hmm, I think the difficulty is to track the index of the current layout
> in the layouts array. I'm not sure how. I'd like to stick with the
> current Monitor struct.
Hmm, ok.
>> 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. ;)
>
> Well, it's a compromise. Would you feel it's less ugly if I define the
> apply_mslts function like this:
>
> tatic void apply_mslts(Monitor *m, Bool hsplit,
> float mfact, int nmaster,
> void (*mltf)(Client **, Booth *, unsigned int),
> void (*sltf)(Client **, Booth *, unsigned int)) {
> /* uses mfact instead of m->mfact, nmaster intead of m->nmaster */
> }
>
> and define the layouts like:
>
> void
> col(Monitor *m) {
> int nmaster = MIN(m->nmaster, m->ww / term_width);
> float mfact = (float)term_width * nmaster / m->ww;
> apply_mslts(m, False, mfact, nmaster, lt_hstack, lt_vstack);
> }
> void
> tile(Monitor *m) {
> apply_mslts(m, False, m->mfact, m->nmaster, lt_vstack, lt_vstack);
> }
>
> Basically the same thing, I guess it's still ugly, but does it feel less
> ugly? :D
I think this is less ugly, because you don't manipulate (like before)
m->{nmaster, mfact}.
Cheers,
Anselm
