</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_window_managers">1. Window Managers</h2>\r
+<h2 id="_building_i3">1. Building i3</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>You can build i3 like you build any other software package which uses autotools.\r
+Here’s a memory refresher:</p></div>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>$ autoreconf -fi\r
+$ mkdir -p build && cd build\r
+$ ../configure\r
+$ make -j8</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p>(The autoreconf -fi step is unnecessary if you are building from a release tarball,\r
+ but shouldn’t hurt either.)</p></div>\r
+<div class="sect2">\r
+<h3 id="_build_system_features">1.1. Build system features</h3>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate\r
+ directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building\r
+ in a separate directory is common practice anyway. In case this causes any\r
+ trouble when packaging i3 for your distribution, please open an issue.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make check” runs the i3 testsuite. See docs/testsuite for details.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make distcheck” (runs testsuite on “make dist” result, tiny bit quicker\r
+ feedback cycle than waiting for the travis build to catch the issue).\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make uninstall” (occasionally requested by users who compile from source)\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+“make” will build manpages/docs by default if the tools are installed.\r
+ Conversely, manpages/docs are not tried to be built for users who don’t want\r
+ to install all these dependencies to get started hacking on i3.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+non-release builds will enable address sanitizer by default. Use the\r
+ --disable-sanitizers configure option to turn off all sanitizers, and see\r
+ --help for available sanitizers.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Support for pre-compiled headers (PCH) has been dropped for now in the\r
+ interest of simplicity. If you need support for PCH, please open an issue.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Coverage reports are now generated using “make check-code-coverage”, which\r
+ requires specifying --enable-code-coverage when calling configure.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_using_git_sending_patches">2. Using git / sending patches</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>For a short introduction into using git, see\r
+<a href="https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy">https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy</a>\r
+or, for more documentation, see <a href="https://git-scm.com/documentation">https://git-scm.com/documentation</a></p></div>\r
+<div class="paragraph"><p>Please talk to us before working on new features to see whether they will be\r
+accepted. A good way for this is to open an issue and asking for opinions on it.\r
+Even for accepted features, this can be a good way to refine an idea upfront. However,\r
+we don’t want to see certain features in i3, e.g., switching window focus in an\r
+Alt+Tab like way.</p></div>\r
+<div class="paragraph"><p>When working on bugfixes, please make sure you mention that you are working on\r
+it in the corresponding bug report at <a href="https://github.com/i3/i3/issues">https://github.com/i3/i3/issues</a>. In case\r
+there is no bug report yet, please create one.</p></div>\r
+<div class="paragraph"><p>After you are done, please submit your work for review as a pull request at\r
+<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>.</p></div>\r
+<div class="paragraph"><p>Do not send emails to the mailing list or any author directly, and don’t submit\r
+them in the bugtracker, since all reviews should be done in public at\r
+<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>. In order to make your review go as fast as possible, you\r
+could have a look at previous reviews and see what the common mistakes are.</p></div>\r
+<div class="sect2">\r
+<h3 id="_which_branch_to_use">2.1. Which branch to use?</h3>\r
+<div class="paragraph"><p>Work on i3 generally happens in two branches: “master” and “next” (the latter\r
+being the default branch, the one that people get when they check out the git\r
+repository).</p></div>\r
+<div class="paragraph"><p>The contents of “master” are always stable. That is, it contains the source code\r
+of the latest release, plus any bugfixes that were applied since that release.</p></div>\r
+<div class="paragraph"><p>New features are only found in the “next” branch. Therefore, if you are working\r
+on a new feature, use the “next” branch. If you are working on a bugfix, use the\r
+“next” branch, too, but make sure your code also works on “master”.</p></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_window_managers">3. Window Managers</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>A window manager is not necessarily needed to run X, but it is usually used in\r
combination with X to facilitate some things. The window manager’s job is to\r
<div class="paragraph"><p>In the following chapters, each of these tasks and their implementation details\r
will be discussed.</p></div>\r
<div class="sect2">\r
-<h3 id="_tiling_window_managers">1.1. Tiling window managers</h3>\r
+<h3 id="_tiling_window_managers">3.1. Tiling window managers</h3>\r
<div class="paragraph"><p>Traditionally, there are two approaches to managing windows: The most common\r
one nowadays is floating, which means the user can freely move/resize the\r
windows. The other approach is called tiling, which means that your window\r
the layout you need at the moment.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_the_layout_tree">1.2. The layout tree</h3>\r
+<h3 id="_the_layout_tree">3.2. The layout tree</h3>\r
<div class="paragraph"><p>The data structure which i3 uses to keep track of your windows is a tree. Every\r
node in the tree is a container (type <tt>Con</tt>). Some containers represent actual\r
windows (every container with a <tt>window != NULL</tt>), some represent split\r
workspace, the split container we are talking about is the workspace.</p></div>\r
<div class="paragraph"><p>To get an impression of how different layouts are represented, just play around\r
and look at the data structures — they are exposed as a JSON hash. See\r
-<a href="http://i3wm.org/docs/ipc.html#_tree_reply">http://i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that and an\r
+<a href="https://i3wm.org/docs/ipc.html#_tree_reply">https://i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that and an\r
example.</p></div>\r
</div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_files">2. Files</h2>\r
+<h2 id="_files">4. Files</h2>\r
<div class="sectionbody">\r
<div class="dlist"><dl>\r
<dt class="hdlist1">\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_data_structures">3. Data structures</h2>\r
+<h2 id="_data_structures">5. Data structures</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>See include/data.h for documented data structures. The most important ones are\r
explained right here.</p></div>\r
</ol></div>\r
<div class="paragraph"><p>The data type is <tt>Con</tt>, in all cases.</p></div>\r
<div class="sect2">\r
-<h3 id="_x11_root_window">3.1. X11 root window</h3>\r
+<h3 id="_x11_root_window">5.1. X11 root window</h3>\r
<div class="paragraph"><p>The X11 root window is a single window per X11 display (a display is identified\r
by <tt>:0</tt> or <tt>:1</tt> etc.). The root window is what you draw your background image\r
on. It spans all the available outputs, e.g. <tt>VGA1</tt> is a specific part of the\r
root window and <tt>LVDS1</tt> is a specific part of the root window.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_output_container">3.2. Output container</h3>\r
+<h3 id="_output_container">5.2. Output container</h3>\r
<div class="paragraph"><p>Every active output obtained through RandR is represented by one output\r
container. Outputs are considered active when a mode is configured (meaning\r
something is actually displayed on the output) and the output is not a clone.</p></div>\r
currently on.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_content_container">3.3. Content container</h3>\r
+<h3 id="_content_container">5.3. Content container</h3>\r
<div class="paragraph"><p>Each output has multiple children. Two of them are dock containers which hold\r
dock clients. The other one is the content container, which holds the actual\r
content (workspaces) of this output.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_workspace">3.4. Workspace</h3>\r
+<h3 id="_workspace">5.4. Workspace</h3>\r
<div class="paragraph"><p>A workspace is identified by its name. Basically, you could think of\r
workspaces as different desks in your office, if you like the desktop\r
metaphor. They just contain different sets of windows and are completely\r
desktops”.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_split_container">3.5. Split container</h3>\r
+<h3 id="_split_container">5.5. Split container</h3>\r
<div class="paragraph"><p>A split container is a container which holds an arbitrary amount of split\r
containers or X11 window containers. It has an orientation (horizontal or\r
vertical) and a layout.</p></div>\r
containers) can have different border styles.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_x11_window_container">3.6. X11 window container</h3>\r
+<h3 id="_x11_window_container">5.6. X11 window container</h3>\r
<div class="paragraph"><p>An X11 window container holds exactly one X11 window. These are the leaf nodes\r
of the layout tree, they cannot have any children.</p></div>\r
</div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_list_queue_macros">4. List/queue macros</h2>\r
+<h2 id="_list_queue_macros">6. List/queue macros</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>i3 makes heavy use of the list macros defined in BSD operating systems. To\r
ensure that the operating system on which i3 is compiled has all the expected\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_naming_conventions">5. Naming conventions</h2>\r
+<h2 id="_naming_conventions">7. Naming conventions</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>There is a row of standard variables used in many events. The following names\r
should be chosen for those:</p></div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_startup_src_mainx_c_main">6. Startup (src/mainx.c, main())</h2>\r
+<h2 id="_startup_src_mainx_c_main">8. Startup (src/mainx.c, main())</h2>\r
<div class="sectionbody">\r
<div class="ulist"><ul>\r
<li>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_keybindings">7. Keybindings</h2>\r
+<h2 id="_keybindings">9. Keybindings</h2>\r
<div class="sectionbody">\r
<div class="sect2">\r
-<h3 id="_grabbing_the_bindings">7.1. Grabbing the bindings</h3>\r
+<h3 id="_grabbing_the_bindings">9.1. Grabbing the bindings</h3>\r
<div class="paragraph"><p>Grabbing the bindings is quite straight-forward. You pass X your combination of\r
modifiers and the keycode you want to grab and whether you want to grab them\r
actively or passively. Most bindings (everything except for bindings using\r
will handle the event, if not, it will replay the event.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_handling_a_keypress">7.2. Handling a keypress</h3>\r
+<h3 id="_handling_a_keypress">9.2. Handling a keypress</h3>\r
<div class="paragraph"><p>As mentioned in "Grabbing the bindings", upon a keypress event, i3 first gets\r
the correct state.</p></div>\r
<div class="paragraph"><p>Then, it looks through all bindings and gets the one which matches the received\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_manage_windows_src_main_c_manage_window_and_reparent_window">8. Manage windows (src/main.c, manage_window() and reparent_window())</h2>\r
+<h2 id="_manage_windows_src_main_c_manage_window_and_reparent_window">10. Manage windows (src/main.c, manage_window() and reparent_window())</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p><tt>manage_window()</tt> does some checks to decide whether the window should be\r
managed at all:</p></div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_what_happens_when_an_application_is_started">9. What happens when an application is started?</h2>\r
+<h2 id="_what_happens_when_an_application_is_started">11. What happens when an application is started?</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>i3 does not care about applications. All it notices is when new windows are\r
mapped (see <tt>src/handlers.c</tt>, <tt>handle_map_request()</tt>). The window is then\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_net_wm_state">10. _NET_WM_STATE</h2>\r
+<h2 id="_net_wm_state">12. _NET_WM_STATE</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Only the _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_DEMANDS_ATTENTION atoms\r
are handled.</p></div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_wm_name">11. WM_NAME</h2>\r
+<h2 id="_wm_name">13. WM_NAME</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>When the WM_NAME property of a window changes, its decoration (containing the\r
title) is re-rendered. Note that WM_NAME is in COMPOUND_TEXT encoding which is\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_net_wm_name">12. _NET_WM_NAME</h2>\r
+<h2 id="_net_wm_name">14. _NET_WM_NAME</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Like WM_NAME, this atom contains the title of a window. However, _NET_WM_NAME\r
is encoded in UTF-8. i3 will recode it to UCS-2 in order to be able to pass it\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_size_hints">13. Size hints</h2>\r
+<h2 id="_size_hints">15. Size hints</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Size hints specify the minimum/maximum size for a given window as well as its\r
aspect ratio. This is important for clients like mplayer, who only set the\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_rendering_src_layout_c_render_layout_and_render_container">14. Rendering (src/layout.c, render_layout() and render_container())</h2>\r
+<h2 id="_rendering_src_layout_c_render_layout_and_render_container">16. Rendering (src/layout.c, render_layout() and render_container())</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Rendering in i3 version 4 is the step which assigns the correct sizes for\r
borders, decoration windows, child windows and the stacking order of all\r
about the different rendering steps, in the order of "top of the tree" (root\r
container) to the bottom.</p></div>\r
<div class="sect2">\r
-<h3 id="_rendering_the_root_container">14.1. Rendering the root container</h3>\r
+<h3 id="_rendering_the_root_container">16.1. Rendering the root container</h3>\r
<div class="paragraph"><p>The i3 root container (<tt>con->type == CT_ROOT</tt>) represents the X11 root window.\r
It contains one child container for every output (like LVDS1, VGA1, …), which\r
is available on your computer.</p></div>\r
only called for the global fullscreen window.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_rendering_an_output">14.2. Rendering an output</h3>\r
+<h3 id="_rendering_an_output">16.2. Rendering an output</h3>\r
<div class="paragraph"><p>Output containers (<tt>con->layout == L_OUTPUT</tt>) represent a hardware output like\r
LVDS1, VGA1, etc. An output container has three children (at the moment): One\r
content container (having workspaces as children) and the top/bottom dock area\r
</ol></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_rendering_a_workspace_or_split_container">14.3. Rendering a workspace or split container</h3>\r
+<h3 id="_rendering_a_workspace_or_split_container">16.3. Rendering a workspace or split container</h3>\r
<div class="paragraph"><p>From here on, there really is no difference anymore. All containers are of\r
<tt>con->type == CT_CON</tt> (whether workspace or split container) and some of them\r
have a <tt>con->window</tt>, meaning they represent an actual window instead of a\r
split container.</p></div>\r
<div class="sect3">\r
-<h4 id="_default_layout">14.3.1. Default layout</h4>\r
+<h4 id="_default_layout">16.3.1. Default layout</h4>\r
<div class="paragraph"><p>In default layout, containers are placed horizontally or vertically next to\r
each other (depending on the <tt>con->orientation</tt>). If a child is a leaf node (as\r
opposed to a split container) and has border style "normal", appropriate space\r
will be reserved for its window decoration.</p></div>\r
</div>\r
<div class="sect3">\r
-<h4 id="_stacked_layout">14.3.2. Stacked layout</h4>\r
+<h4 id="_stacked_layout">16.3.2. Stacked layout</h4>\r
<div class="paragraph"><p>In stacked layout, only the focused window is actually shown (this is achieved\r
by calling <tt>x_raise_con()</tt> in reverse focus order at the end of <tt>render_con()</tt>).</p></div>\r
<div class="paragraph"><p>The available space for the focused window is the size of the container minus\r
the stacked container.</p></div>\r
</div>\r
<div class="sect3">\r
-<h4 id="_tabbed_layout">14.3.3. Tabbed layout</h4>\r
+<h4 id="_tabbed_layout">16.3.3. Tabbed layout</h4>\r
<div class="paragraph"><p>Tabbed layout works precisely like stacked layout, but the window decoration\r
position/size is different: They are placed next to each other on a single line\r
(fixed height).</p></div>\r
</div>\r
<div class="sect3">\r
-<h4 id="_dock_area_layout">14.3.4. Dock area layout</h4>\r
+<h4 id="_dock_area_layout">16.3.4. Dock area layout</h4>\r
<div class="paragraph"><p>This is a special case. Users cannot choose the dock area layout, but it will be\r
set for the dock area containers. In the dockarea layout (at the moment!),\r
windows will be placed above each other.</p></div>\r
</div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_rendering_a_window">14.4. Rendering a window</h3>\r
+<h3 id="_rendering_a_window">16.4. Rendering a window</h3>\r
<div class="paragraph"><p>A window’s size and position will be determined in the following way:</p></div>\r
<div class="olist arabic"><ol class="arabic">\r
<li>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_pushing_updates_to_x11_drawing">15. Pushing updates to X11 / Drawing</h2>\r
+<h2 id="_pushing_updates_to_x11_drawing">17. Pushing updates to X11 / Drawing</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>A big problem with i3 before version 4 was that we just sent requests to X11\r
anywhere in the source code. This was bad because nobody could understand the\r
</li>\r
</ol></div>\r
<div class="sect2">\r
-<h3 id="_pushing_state_to_x11">15.1. Pushing state to X11</h3>\r
+<h3 id="_pushing_state_to_x11">17.1. Pushing state to X11</h3>\r
<div class="paragraph"><p>In general, the function <tt>x_push_changes</tt> should be called to push state\r
changes. Only when the scope of the state change is clearly defined (for\r
example only the title of a window) and its impact is known beforehand, one can\r
<tt>WM_STATE_WITHDRAWN</tt>.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_drawing_window_decorations_borders_backgrounds">15.2. Drawing window decorations/borders/backgrounds</h3>\r
+<h3 id="_drawing_window_decorations_borders_backgrounds">17.2. Drawing window decorations/borders/backgrounds</h3>\r
<div class="paragraph"><p><tt>x_draw_decoration</tt> draws window decorations. It is run for every leaf\r
container (representing an actual X11 window) and for every non-leaf container\r
which is in a stacked/tabbed container (because stacked/tabbed containers\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_user_commands_parser_specs_commands_spec">16. User commands (parser-specs/commands.spec)</h2>\r
+<h2 id="_user_commands_parser_specs_commands_spec">18. User commands (parser-specs/commands.spec)</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>In the configuration file and when using i3 interactively (with <tt>i3-msg</tt>, for\r
example), you use commands to make i3 do things, like focus a different window,\r
in which the parser will transition into, or the keyword <em>call</em>, followed by\r
the name of a function (and optionally a state).</p></div>\r
<div class="sect2">\r
-<h3 id="_example_the_workspace_state">16.1. Example: The WORKSPACE state</h3>\r
+<h3 id="_example_the_workspace_state">18.1. Example: The WORKSPACE state</h3>\r
<div class="paragraph"><p>Let’s have a look at the WORKSPACE state, which is a good example of all\r
features. This is its definition:</p></div>\r
<div class="listingblock">\r
</dl></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_introducing_a_new_command">16.2. Introducing a new command</h3>\r
+<h3 id="_introducing_a_new_command">18.2. Introducing a new command</h3>\r
<div class="paragraph"><p>The following steps have to be taken in order to properly introduce a new\r
command (or possibly extend an existing command):</p></div>\r
<div class="olist arabic"><ol class="arabic">\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_moving_containers">17. Moving containers</h2>\r
+<h2 id="_moving_containers">19. Moving containers</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>The movement code is pretty delicate. You need to consider all cases before\r
making any changes or before being able to fully understand how it works.</p></div>\r
<div class="sect2">\r
-<h3 id="_case_1_moving_inside_the_same_container">17.1. Case 1: Moving inside the same container</h3>\r
+<h3 id="_case_1_moving_inside_the_same_container">19.1. Case 1: Moving inside the same container</h3>\r
<div class="paragraph"><p>The reference layout for this case is a single workspace in horizontal\r
orientation with two containers on it. Focus is on the left container (1).</p></div>\r
<div class="tableblock">\r
of the current one and swaps both containers.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_2_move_a_container_into_a_split_container">17.2. Case 2: Move a container into a split container</h3>\r
+<h3 id="_case_2_move_a_container_into_a_split_container">19.2. Case 2: Move a container into a split container</h3>\r
<div class="paragraph"><p>The reference layout for this case is a horizontal workspace with two\r
containers. The right container is a v-split with two containers. Focus is on\r
the left container (1).</p></div>\r
be flattened.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_3_moving_to_non_existent_top_bottom">17.3. Case 3: Moving to non-existent top/bottom</h3>\r
+<h3 id="_case_3_moving_to_non_existent_top_bottom">19.3. Case 3: Moving to non-existent top/bottom</h3>\r
<div class="paragraph"><p>Like in case 1, the reference layout for this case is a single workspace in\r
horizontal orientation with two containers on it. Focus is on the left\r
container:</p></div>\r
flattened.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_4_moving_to_existent_top_bottom">17.4. Case 4: Moving to existent top/bottom</h3>\r
+<h3 id="_case_4_moving_to_existent_top_bottom">19.4. Case 4: Moving to existent top/bottom</h3>\r
<div class="paragraph"><p>The reference layout for this case is a vertical workspace with two containers.\r
The bottom one is a h-split containing two containers (1 and 2). Focus is on\r
the bottom left container (1).</p></div>\r
is in vertical orientation.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_5_moving_in_one_child_h_split">17.5. Case 5: Moving in one-child h-split</h3>\r
+<h3 id="_case_5_moving_in_one_child_h_split">19.5. Case 5: Moving in one-child h-split</h3>\r
<div class="paragraph"><p>The reference layout for this case is a horizontal workspace with two\r
containers having a v-split on the left side with a one-child h-split on the\r
bottom. Focus is on the bottom left container (2(h)):</p></div>\r
4.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_6_floating_containers">17.6. Case 6: Floating containers</h3>\r
+<h3 id="_case_6_floating_containers">19.6. Case 6: Floating containers</h3>\r
<div class="paragraph"><p>The reference layout for this case is a horizontal workspace with two\r
containers plus one floating h-split container. Focus is on the floating\r
container.</p></div>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_click_handling">18. Click handling</h2>\r
+<h2 id="_click_handling">20. Click handling</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Without much ado, here is the list of cases which need to be considered:</p></div>\r
<div class="ulist"><ul>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_gotchas">19. Gotchas</h2>\r
+<h2 id="_gotchas">21. Gotchas</h2>\r
<div class="sectionbody">\r
<div class="ulist"><ul>\r
<li>\r
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_using_git_sending_patches">20. Using git / sending patches</h2>\r
-<div class="sectionbody">\r
-<div class="sect2">\r
-<h3 id="_introduction">20.1. Introduction</h3>\r
-<div class="paragraph"><p>For a short introduction into using git, see\r
-<a href="http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy">http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy</a>\r
-or, for more documentation, see <a href="http://git-scm.com/documentation">http://git-scm.com/documentation</a></p></div>\r
-<div class="paragraph"><p>Please talk to us before working on new features to see whether they will be\r
-accepted. A good way for this is to open an issue and asking for opinions on it.\r
-Even for accepted features, this can be a good way to refine an idea upfront. However,\r
-we don’t want to see certain features in i3, e.g., switching window focus in an\r
-Alt+Tab like way.</p></div>\r
-<div class="paragraph"><p>When working on bugfixes, please make sure you mention that you are working on\r
-it in the corresponding bug report at <a href="https://github.com/i3/i3/issues">https://github.com/i3/i3/issues</a>. In case\r
-there is no bug report yet, please create one.</p></div>\r
-<div class="paragraph"><p>After you are done, please submit your work for review as a pull request at\r
-<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>.</p></div>\r
-<div class="paragraph"><p>Do not send emails to the mailing list or any author directly, and don’t submit\r
-them in the bugtracker, since all reviews should be done in public at\r
-<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>. In order to make your review go as fast as possible, you\r
-could have a look at previous reviews and see what the common mistakes are.</p></div>\r
-</div>\r
-<div class="sect2">\r
-<h3 id="_which_branch_to_use">20.2. Which branch to use?</h3>\r
-<div class="paragraph"><p>Work on i3 generally happens in two branches: “master” and “next” (the latter\r
-being the default branch, the one that people get when they check out the git\r
-repository).</p></div>\r
-<div class="paragraph"><p>The contents of “master” are always stable. That is, it contains the source code\r
-of the latest release, plus any bugfixes that were applied since that release.</p></div>\r
-<div class="paragraph"><p>New features are only found in the “next” branch. Therefore, if you are working\r
-on a new feature, use the “next” branch. If you are working on a bugfix, use the\r
-“next” branch, too, but make sure your code also works on “master”.</p></div>\r
-</div>\r
-<div class="sect2">\r
-<h3 id="_how_to_build">20.3. How to build?</h3>\r
-<div class="paragraph"><p>You can build i3 like you build any other software package which uses autotools.\r
-Here’s a memory refresher:</p></div>\r
-<div class="literalblock">\r
-<div class="content">\r
-<pre><tt>$ autoreconf -fi\r
-$ mkdir -p build && cd build\r
-$ ../configure\r
-$ make -j8</tt></pre>\r
-</div></div>\r
-<div class="paragraph"><p>(The autoreconf -fi step is unnecessary if you are building from a release tarball,\r
- but shouldn’t hurt either.)</p></div>\r
-<div class="sect3">\r
-<h4 id="_build_system_features">20.3.1. Build system features</h4>\r
-<div class="ulist"><ul>\r
-<li>\r
-<p>\r
-We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate\r
- directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building\r
- in a separate directory is common practice anyway. In case this causes any\r
- trouble when packaging i3 for your distribution, please open an issue.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make check” runs the i3 testsuite. See docs/testsuite for details.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make distcheck” (runs testsuite on “make dist” result, tiny bit quicker\r
- feedback cycle than waiting for the travis build to catch the issue).\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make uninstall” (occasionally requested by users who compile from source)\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make” will build manpages/docs by default if the tools are installed.\r
- Conversely, manpages/docs are not tried to be built for users who don’t want\r
- to install all these dependencies to get started hacking on i3.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-non-release builds will enable address sanitizer by default. Use the\r
- --disable-sanitizers configure option to turn off all sanitizers, and see\r
- --help for available sanitizers.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Support for pre-compiled headers (PCH) has been dropped for now in the\r
- interest of simplicity. If you need support for PCH, please open an issue.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Coverage reports are now generated using “make check-code-coverage”, which\r
- requires specifying --enable-code-coverage when calling configure.\r
-</p>\r
-</li>\r
-</ul></div>\r
-</div>\r
-</div>\r
-</div>\r
-</div>\r
-<div class="sect1">\r
-<h2 id="_thought_experiments">21. Thought experiments</h2>\r
+<h2 id="_thought_experiments">22. Thought experiments</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>In this section, we collect thought experiments, so that we don’t forget our\r
thoughts about specific topics. They are not necessary to get into hacking i3,\r
before asking us why things are the way they are or why we don’t implement\r
things.</p></div>\r
<div class="sect2">\r
-<h3 id="_using_cgroups_per_workspace">21.1. Using cgroups per workspace</h3>\r
+<h3 id="_using_cgroups_per_workspace">22.1. Using cgroups per workspace</h3>\r
<div class="paragraph"><p>cgroups (control groups) are a linux-only feature which provides the ability to\r
group multiple processes. For each group, you can individually set resource\r
limits, like allowed memory usage. Furthermore, and more importantly for our\r
projects / i3 / i3.github.io / blobdiff