+<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
+entirety of our interaction with X11, it lead to subtle bugs and a lot of edge\r
+cases which we had to consider all over again.</p></div>\r
+<div class="paragraph"><p>Therefore, since version 4, we have a single file, <tt>src/x.c</tt>, which is\r
+responsible for repeatedly transferring parts of our tree datastructure to X11.</p></div>\r
+<div class="paragraph"><p><tt>src/x.c</tt> consists of multiple parts:</p></div>\r
+<div class="olist arabic"><ol class="arabic">\r
+<li>\r
+<p>\r
+The state pushing: <tt>x_push_changes()</tt>, which calls <tt>x_push_node()</tt>.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+State modification functions: <tt>x_con_init</tt>, <tt>x_reinit</tt>,\r
+ <tt>x_reparent_child</tt>, <tt>x_move_win</tt>, <tt>x_con_kill</tt>, <tt>x_raise_con</tt>, <tt>x_set_name</tt>\r
+ and <tt>x_set_warp_to</tt>.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Expose event handling (drawing decorations): <tt>x_deco_recurse()</tt> and\r
+ <tt>x_draw_decoration()</tt>.\r
+</p>\r
+</li>\r
+</ol></div>\r
+<div class="sect2">\r
+<h3 id="_pushing_state_to_x11">15.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
+optimize this and call <tt>x_push_node</tt> on the appropriate con directly.</p></div>\r
+<div class="paragraph"><p><tt>x_push_changes</tt> works in the following steps:</p></div>\r
+<div class="olist arabic"><ol class="arabic">\r
+<li>\r
+<p>\r
+Clear the eventmask for all mapped windows. This leads to not getting\r
+ useless ConfigureNotify or EnterNotify events which are caused by our\r
+ requests. In general, we only want to handle user input.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Stack windows above each other, in reverse stack order (starting with the\r
+ most obscured/bottom window). This is relevant for floating windows which\r
+ can overlap each other, but also for tiling windows in stacked or tabbed\r
+ containers. We also update the <tt>_NET_CLIENT_LIST_STACKING</tt> hint which is\r
+ necessary for tab drag and drop in Chromium.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>x_push_node</tt> will be called for the root container, recursively calling\r
+ itself for the container’s children. This function actually pushes the\r
+ state, see the next paragraph.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If the pointer needs to be warped to a different position (for example when\r
+ changing focus to a differnt output), it will be warped now.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+The eventmask is restored for all mapped windows.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Window decorations will be rendered by calling <tt>x_deco_recurse</tt> on the root\r
+ container, which then recursively calls itself for the children.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If the input focus needs to be changed (because the user focused a different\r
+ window), it will be updated now.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>x_push_node_unmaps</tt> will be called for the root container. This function\r
+ only pushes UnmapWindow requests. Separating the state pushing is necessary\r
+ to handle fullscreen windows (and workspace switches) in a smooth fashion:\r
+ The newly visible windows should be visible before the old windows are\r
+ unmapped.\r
+</p>\r
+</li>\r
+</ol></div>\r
+<div class="paragraph"><p><tt>x_push_node</tt> works in the following steps:</p></div>\r
+<div class="olist arabic"><ol class="arabic">\r
+<li>\r
+<p>\r
+Update the window’s <tt>WM_NAME</tt>, if changed (the <tt>WM_NAME</tt> is set on i3\r
+ containers mainly for debugging purposes).\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Reparents a child window into the i3 container if the container was created\r
+ for a specific managed window.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If the size/position of the i3 container changed (due to opening a new\r
+ window or switching layouts for example), the window will be reconfigured.\r
+ Also, the pixmap which is used to draw the window decoration/border on is\r
+ reconfigured (pixmaps are size-dependent).\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Size/position for the child window is adjusted.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+The i3 container is mapped if it should be visible and was not yet mapped.\r
+ When mapping, <tt>WM_STATE</tt> is set to <tt>WM_STATE_NORMAL</tt>. Also, the eventmask of\r
+ the child window is updated and the i3 container’s contents are copied from\r
+ the pixmap.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>x_push_node</tt> is called recursively for all children of the current\r
+ container.\r
+</p>\r
+</li>\r
+</ol></div>\r
+<div class="paragraph"><p><tt>x_push_node_unmaps</tt> handles the remaining case of an i3 container being\r
+unmapped if it should not be visible anymore. <tt>WM_STATE</tt> will be set to\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
+<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
+display a window decoration for split containers, which at the moment just says\r
+"another container").</p></div>\r
+<div class="paragraph"><p>Then, parameters are collected to be able to determine whether this decoration\r
+drawing is actually necessary or was already done. This saves a substantial\r
+number of redraws (depending on your workload, but far over 50%).</p></div>\r
+<div class="paragraph"><p>Assuming that we need to draw this decoration, we start by filling the empty\r
+space around the child window (think of MPlayer with a specific aspect ratio)\r
+in the user-configured client background color.</p></div>\r
+<div class="paragraph"><p>Afterwards, we draw the appropriate border (in case of border styles "normal"\r
+and "1pixel") and the top bar (in case of border style "normal").</p></div>\r
+<div class="paragraph"><p>The last step is drawing the window title on the top bar.</p></div>\r
+</div>\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
+<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
+set a window to fullscreen, and so on. An example command is <tt>floating enable</tt>,\r
+which enables floating mode for the currently focused window. See the\r
+appropriate section in the <a href="userguide.html">User’s Guide</a> for a reference of\r
+all commands.</p></div>\r
+<div class="paragraph"><p>In earlier versions of i3, interpreting these commands was done using lex and\r
+yacc, but experience has shown that lex and yacc are not well suited for our\r
+command language. Therefore, starting from version 4.2, we use a custom parser\r
+for user commands (not yet for the configuration file).\r
+The input specification for this parser can be found in the file\r
+<tt>parser-specs/commands.spec</tt>. Should you happen to use Vim as an editor, use\r
+:source parser-specs/highlighting.vim to get syntax highlighting for this file\r
+(highlighting files for other editors are welcome).</p></div>\r
+<div class="listingblock">\r
+<div class="title">Excerpt from commands.spec</div>\r