commit 541ff09501e5ae39b080a0fd8eb94cb97b82194f
parent 86378f819d2278eb3b9bae11fac8bae187687ff1
Author: memeplex <carlosjosepita@gmail.com>
Date: Mon, 13 Jan 2014 21:38:16 -0300
Minor documentation updates and corrections.
Diffstat:
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/dwm.suckless.org/patches/gaps.md b/dwm.suckless.org/patches/gaps.md
@@ -6,7 +6,7 @@ Description
-----------
This patch modifies the tile layout to add a gap between clients that helps to visually
-diferentiate between selected borders and normal borders and so provides an additional
+differentiate between selected borders and normal borders and so provides an additional
visual hint to identify the currently selected client. OTOH, there's no gap between a
client and the screen frame in order to reduce the waste of screen space.
diff --git a/dwm.suckless.org/patches/pango.md b/dwm.suckless.org/patches/pango.md
@@ -26,7 +26,7 @@ not possible under barebone xft:
[1] The [Icons family](https://aur.archlinux.org/packages/ttf-font-icons/) is a
non-overlapping merge of Awesome and Ionicons fonts I've made for my statusbar. In case
you want to take a look at it, there is a
- [cheatsheet](https://www.dropbox.com/s/ske86jxsslpyx3a/icons.pdf) listing the icons and
+ [cheatsheet](https://www.dropbox.com/s/9iysh2i0gadi4ic/icons.pdf) listing the icons and
their unicode points.
Download
diff --git a/dwm.suckless.org/patches/xtile.md b/dwm.suckless.org/patches/xtile.md
@@ -9,10 +9,10 @@ This patch implements a generalization of the tile layout which adds two attribu
allocatable visual space and it's subdivided into the master and stack subareas.
The direction of the global area controls the position of the master area relatively to
-the stack area and it can be one of `DirHor(0)` (traditional right stack), `DirVer(1)`
-(bottom stack), `DirRotHor` (left stack) and `DirRotVer` (top stack). The direction of the
-master and of the stack areas are independently set and can be one of `DirHor(0)` and
-`DirVer(1)`. This combines to a total of 4\*2\*2=16 layouts.
+the stack area and it can be one of `DirHor` (traditional right stack), `DirVer` (bottom
+stack), `DirRotHor` (left stack) and `DirRotVer` (top stack). The direction of the master
+and of the stack areas are independently set and can be one of `DirHor` and `DirVer`.
+This combines to a total of 4\*2\*2=16 layouts.
The fact numbers indicate the relative size of the first subarea/client along the
direction of the considered area (i.e. width for `DirHor` and `DirRotHor` and height for
@@ -115,14 +115,14 @@ me how to allow the specification of facts for the first two clients in an intui
One obvious additional generalization would have been to extrapolate the nmaster idea to
all three areas, or at least to the stack area. So if you allowed only m masters and n
slaves you would end up with m+n tiled windows and with the rest of the clients in the
-current tagset stacked or decked "below" the last tiled client. flextile, clients-per-tag
-and deck patches provide variations on this kind of layout. I've also implemented a
-version of xtile that supports it and even subsumes monocle, but I think this promotes a
-bad pattern of usage. Coupled with stack manipulation operations as the ones provided by
-the stacker or push patches, there is the temptation to manage visibility by moving the
-desired clients in the current tag to the first n+m visible positions of the focus stack
-(not to be confused with the stack area). There are a number of problems with this
-approach:
+current tagset stacked or decked "below" the last tiled client. flextile,
+clients-per-tag and deck patches provide variations on this kind of layout. I've also
+implemented a version of xtile that supports it and even subsumes monocle, but I think
+this promotes a bad pattern of usage. Coupled with stack manipulation operations as the
+ones provided by the stacker or push patches, there is the temptation to manage visibility
+by moving the desired clients in the current tagset to the first n+m visible positions of
+the focus stack (not to be confused with the stack area). There are a number of problems
+with this approach:
* The stack is global to dwm, so pushing around clients in one tag will rearrange them in
other tags also. This could become a problem if you rely too much on explicit stack
@@ -155,7 +155,8 @@ Mandatory dependencies:
* [pertag](pertag): we all know this one.
-Related patches: [bottom stack](bottom_stack), [flextile](flextile).
+Related patches: [bottom stack](bottom_stack), [flextile](flextile), cfacts,
+[stackmfact](stackmfact).
Download
--------
