I believe every master-slave layout, i.e., layouts where mfact/nmaster
make sense, should own its own mfact/nmaster value, not to be disturbed
by other layouts. As said before, `col' and `tile' for example just
can't share the same mfact and still both look good.
Consequently, I decided to update
On 1 November 2011 17:04, lolilolicon wrote:
> On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe 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 Monito
On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe wrote:
> On 1 November 2011 16:27, lolilolicon 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 setmf
On 1 November 2011 16:27, lolilolicon wrote:
> On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe 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 variable
On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe wrote:
> On 1 November 2011 00:07, lolilolicon 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
On 1 November 2011 02:10, lolilolicon wrote:
> On Tue, Nov 1, 2011 at 7:36 AM, Rob wrote:
>>
>> I don't have much time today, or possibly tomorrow, but I'm interested
>> in this patch, it sounds almost like it recurses on each sub-section of
>> the total area, applying a different layout function
On 1 November 2011 00:07, lolilolicon 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
On Tue, Nov 1, 2011 at 7:36 AM, Rob wrote:
>
> I don't have much time today, or possibly tomorrow, but I'm interested
> in this patch, it sounds almost like it recurses on each sub-section of
> the total area, applying a different layout function each time, except
> it's limited to two calls, one
On 31 October 2011 23:07, lolilolicon 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
On Tue, Nov 1, 2011 at 12:11 AM, lolilolicon wrote:
>
> Actually, `apply_lt` can be removed, since `apply_mslts` does the same
> thing when nmaster == 0. I'm thinking of making nmaster a member of
> the Layout structure, instead of the current Monitor. This way, we can
> make all windows slaves
On Mon, Oct 31, 2011 at 10:19 PM, Thomas Dahms wrote:
>
> That looks interesting. I have one suggestion for a simplification:
> I guess you can get rid of the functions combining the master and
> slave layouts by modifying setlayout() to take three arguments (the
> two layouts and the direction of
2011/10/31 lolilolicon :
> On Mon, Oct 31, 2011 at 9:49 PM, lolilolicon wrote:
>>
>> The code is in the attachment.
>>
>
> *huge facepalm*
>
> Forgot to attach the fixed code. Attached here.
>
That looks interesting. I have one suggestion for a simplification:
I guess you can get rid of the func
On Mon, Oct 31, 2011 at 9:49 PM, lolilolicon wrote:
>
> The code is in the attachment.
>
*huge facepalm*
Forgot to attach the fixed code. Attached here.
typedef struct {
int x, y, w, h;
} Booth;
static void apply_lt(Monitor *m, void (*ltf)(Client **, Booth *, unsigned int));
static void apply
13 matches
Mail list logo
