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>