index.md - sites - public wiki contents of suckless.org
(HTM) git clone git://git.suckless.org/sites
(DIR) Log
(DIR) Files
(DIR) Refs
---
index.md (8737B)
---
1 xtile
2 =====
3
4 Description
5 -----------
6 This patch implements a generalization of the tile layout which adds two
7 attributes (direction and fact) to three areas (global, master, stack). The
8 global area is the entire allocatable visual space and it's subdivided into the
9 master and stack subareas.
10
11 The direction of the global area controls the position of the master area
12 relatively to the stack area and it can be one of `DirHor` (traditional right
13 stack), `DirVer` (bottom stack), `DirRotHor` (left stack) and `DirRotVer` (top
14 stack). The direction of the master and of the stack areas are independently
15 set and can be one of `DirHor` and `DirVer`. This combines to a total of
16 4\*2\*2=16 layouts.
17
18 The fact numbers indicate the relative size of the first subarea/client along
19 the direction of the considered area (i.e. width for `DirHor` and `DirRotHor`
20 and height for `DirVer` and `DirRotVer`). A fact of 1 means that the first
21 subarea/client is on par the rest, while a fact of 2 means that its size must
22 double the size of each of the remaining subareas/clients, etc. So the fact for
23 the global area is similar to the traditional mfact in the sense that it
24 manages the relative allocation of visual space between the master and stack
25 subareas, while the fact for the master area stands for the relative importance
26 of the first master client against the rest of masters and, similarly, the fact
27 for the stack area stands for the importance of the first slave client in
28 relation to the rest of slaves.
29
30 xtile adds two new commands to dwm: `setdir` and `setfact` (which supersedes
31 `setmfact`). Both commands take an array of three values (of type `int` for
32 `setdir` and `float` for `setfact`), one value for each area (the first one for
33 the global area, the second one for the master area and the third one for the
34 stack area). If you pass the value `v` as `INC(v)` it will be taken as a
35 relative increment to be added to the current value, otherwise it will be taken
36 as an absolute value. Usually the resulting value will be truncated to the
37 valid range of values for each area/attribute combination, but relative
38 increments for directions wrap around the limits of the valid range. Notice
39 that INC(0) means "do nothing here", so it gives you a way to easily modify the
40 value for some area while leaving the rest untouched.
41
42 Default key bindings
43 --------------------
44 The areas are selected by modifiers as follows:
45
46 Modifier Area
47 --------------------------------------------------------
48 MODKEY Global
49 MODKEY+Shift Master
50 MODKEY+Control Stack
51 MODKEY+Shift+Control All three areas simultaneously
52
53 Each of the modifiers then combines with each of the following keys up to a
54 total of 4\*3=12 key bindings:
55
56 Key Function
57 ------------------------------
58 r Rotate direction
59 h Decrement fact by 10%.
60 l Increment fact by 10%.
61
62 There are two provided default "presets" or "schemas" also:
63
64 Modifier Key Preset
65 --------------------------------------:
66 MODKEY+Shift t Right stack
67 MODKEY+Control t Bottom stack
68
69 These presets allow to quickly switch between different no-nonsense tilings
70 avoiding the need to rotate through all the nonsense combinations in-between.
71 But notice that `MODKEY+Shift+Control+r` (i.e. simultaneously rotate all three
72 areas) usually produces sensible layouts (due to the way directions were
73 designed to rotate).
74
75 You can also easily define your own presets by calling `setdir` and `setfact`
76 as needed. For example, here is the configuration code for the default presets
77 described above:
78
79 { MODKEY|ShiftMask, XK_t, setdirs, {.v = (int[]){ DirHor, DirVer, DirVer } } },
80 { MODKEY|ControlMask, XK_t, setdirs, {.v = (int[]){ DirVer, DirHor, DirHor } } },
81
82 Layout symbol
83 -------------
84
85 The layout symbol will probably look cryptic at first sight but it's very
86 easily decoded. It consists of three characters, one for the direction of each
87 area:
88
89 * Global area: '<', '>', 'v', '^', just think of it as an arrow that points in the
90 direction of the master area.
91 * Master area: '|' for vertically tiled masters and '-' for horizontally tiled masters.
92 * Stack area: same as for the master area.
93
94 For example, '<||' stands for the default right stack tile provided by dwm and
95 '^--' stands for bstack (as defined by the bottom stack patch).
96
97 Digressions
98 -----------
99
100 ### Why facts per area?
101
102 There is some arbitrariness in the way facts are defined by xtile: why facts
103 for the first master and the first slave and not, say, for the first two
104 clients instead? Considering that most real life layouts will have one or two
105 masters and a variable number of slaves, the road xtile took will enable the
106 user to effectively control the relative size of the three/four most important
107 clients in a very intuitive way that built on his previous understanding of the
108 mfact and the master and stack area concepts. OTOH it's not clear to me how to
109 allow the specification of facts for the first two clients in an intuitive way:
110
111 * If there is only one master this alternative approach is equivalent to
112 xtile's one.
113 * If there are two masters, only one fact will be required to specify the share
114 of the master area that belongs to each one, so what to do with the second
115 fact?
116 * If this second fact is taken as the share of the second master vs the share
117 of the rest (the slaves), it's not clear how to define these inter-area shares.
118
119 ### Why not deck area?
120
121 One obvious additional generalization would have been to extrapolate the
122 nmaster idea to all three areas, or at least to the stack area. So if you
123 allowed only m masters and n slaves you would end up with m+n tiled windows and
124 with the rest of the clients in the current tagset stacked or decked "below"
125 the last tiled client. flextile, clients-per-tag and deck patches provide
126 variations on this kind of layout. I've also implemented a version of xtile
127 that supports it and even subsumes monocle, but I think this promotes a bad
128 pattern of usage. Coupled with stack manipulation operations as the ones
129 provided by the stacker or push patches, there is the temptation to manage
130 visibility by moving the desired clients in the current tagset to the first n+m
131 visible positions of the focus stack (not to be confused with the stack area).
132 There are a number of problems with this approach:
133
134 * The stack is global to dwm, so pushing around clients in one tag will
135 rearrange them in other tags also. This could become a problem if you rely too
136 much on explicit stack management.
137
138 * The deck area badly violates the principle of least surprise. If you only
139 change focus sequentially by using `mod-j`/`mod-k` there is no way to exit the
140 deck at a client different to the last/first decked one. If you use the mouse
141 or the `focusstack` command provided by the stacker patch to jump directly from
142 the deck to a non-decked client, each time you reach the deck again by using
143 `mod-j`/`mod-k` the visible decked client will be replaced by the first/last
144 decked one. In general, there is a devilish interplay of the focus stack and
145 the z-stack that makes the deck unusable as a tabbed view of the decked
146 clients, at least for more than one or two decked clients.
147
148 Fortunately, dwm provides a much better mechanism to restrict visibility: tags.
149 IMO there is no need to provide a half-assed alternative to one of dwm's
150 strongest selling points.
151
152 Mandatory dependencies:
153 * [pertag](../pertag/): we all know this one.
154
155 Download
156 --------
157 * [dwm-xtile-6.2.diff](dwm-xtile-6.2.diff) (11/06/2020)
158 * [dwm-6.0-xtile.diff](dwm-6.0-xtile.diff)
159
160 Recommended complementary patches:
161 ----------------------------------
162 Gaps
163 ----
164 Added a new patch with separate inner and outer gaps which can be adjusted
165 at runtime. Also includes an option to disable gaps when only one window
166 is open (on by default.)
167
168 `Mod+Shift+i/o - increase size (i - inner, o - outer)`
169 `Mod+Control+i/o - decrease size (i - inner, o - outer)`
170 `Mod+Shift+Control+i/o - disable gaps (i - inner, o - outer)`
171
172 Download
173 --------
174 * [dwm-xtile-gaps-6.2.diff](dwm-xtile-gaps-6.2.diff) (15/06/2020)
175 * Visit [gaps](../gaps/) page for older versions.
176
177 Stacker
178 -------
179 A patch to better accommodate the clients to the more elaborate layouts allowed
180 by xtile. But I would add: subject to the caveats that I've expressed above.
181
182 Download
183 --------
184 * Visit [stacker](../stacker/) page to download. (6.2 version available)
185
186 Patches related to xtile:
187 [bottom stack](../bottomstack/), [flextile](../flextile/),
188 [cfacts](../cfacts/), [stackmfact](../stackmfact/).
189
190
191 Authors
192 -------
193 * MLquest8 (gaps and update for 6.2) (miskuzius at gmail.com)
194 * Carlos Pita (memeplex) <carlosjosepita@gmail.com>