public wiki contents of
git clone git://
Log | Files | Refs (8737B)

      1 xtile
      2 =====
      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.
     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.
     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.
     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.
     42 Default key bindings
     43 --------------------
     44 The areas are selected by modifiers as follows:
     46 	 Modifier                Area
     47 	--------------------------------------------------------
     48 	 MODKEY                  Global
     49 	 MODKEY+Shift            Master
     50 	 MODKEY+Control          Stack
     51 	 MODKEY+Shift+Control    All three areas simultaneously
     53 Each of the modifiers then combines with each of the following keys up to a
     54 total of 4\*3=12 key bindings:
     56 	 Key   Function
     57 	------------------------------
     58 	  r    Rotate direction
     59 	  h    Decrement fact by 10%.
     60 	  l    Increment fact by 10%.
     62 There are two provided default "presets" or "schemas" also:
     64 	 Modifier          Key   Preset
     65 	--------------------------------------:
     66 	 MODKEY+Shift       t    Right stack
     67 	 MODKEY+Control     t    Bottom stack
     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).
     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:
     79 	{ MODKEY|ShiftMask,   XK_t, setdirs, {.v = (int[]){ DirHor, DirVer, DirVer } } },
     80 	{ MODKEY|ControlMask, XK_t, setdirs, {.v = (int[]){ DirVer, DirHor, DirHor } } },
     82 Layout symbol
     83 -------------
     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:
     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.
     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).
     97 Digressions
     98 -----------
    100 ### Why facts per area?
    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:
    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.
    119 ### Why not deck area?
    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:
    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.
    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.
    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.
    152 Mandatory dependencies:
    153 * [pertag](../pertag/): we all know this one.
    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)
    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.)
    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)`   
    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.
    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.
    182 Download
    183 --------
    184 * Visit [stacker](../stacker/) page to download. (6.2 version available)
    186 Patches related to xtile:
    187 [bottom stack](../bottomstack/), [flextile](../flextile/), 
    188 [cfacts](../cfacts/), [stackmfact](../stackmfact/).
    191 Authors
    192 -------
    193 * MLquest8 (gaps and update for 6.2) (miskuzius at
    194 * Carlos Pita (memeplex) <>