Re: [dev] Re: [dwm] A general approach to master-slave layouts

From: lolilolicon <lolilolicon_AT_gmail.com>
Date: Wed, 2 Nov 2011 00:04:09 +0800

On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 1 November 2011 16:27, lolilolicon <lolilolicon_AT_gmail.com> wrote:
>> 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 most 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.
>

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.

>> 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 pull request, 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 more 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 more
ugly? :D

>
> Cheers,
> Anselm
>
>
Received on Tue Nov 01 2011 - 17:04:09 CET

This archive was generated by hypermail 2.3.0 : Tue Nov 01 2011 - 17:12:03 CET