+<div class="paragraph"><p>Please note that in the following example, I have left out some keys/values\r
+which are not relevant for the type of the node. Otherwise, the example would\r
+be by far too long (it already is quite long, despite showing only 1 window and\r
+one dock window).</p></div>\r
+<div class="paragraph"><p>It is useful to have an overview of the structure before taking a look at the\r
+JSON dump:</p></div>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+root\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+LVDS1\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+topdock\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+content\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+workspace 1\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+window 1\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+bottomdock\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+dock window 1\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+VGA1\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+</ul></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "id": 6875648,\r
+ "name": "root",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 0,\r
+ "width": 1280,\r
+ "height": 800\r
+ },\r
+ "nodes": [\r
+\r
+ {\r
+ "id": 6878320,\r
+ "name": "LVDS1",\r
+ "layout": "output",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 0,\r
+ "width": 1280,\r
+ "height": 800\r
+ },\r
+ "nodes": [\r
+\r
+ {\r
+ "id": 6878784,\r
+ "name": "topdock",\r
+ "layout": "dockarea",\r
+ "orientation": "vertical",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 0,\r
+ "width": 1280,\r
+ "height": 0\r
+ }\r
+ },\r
+\r
+ {\r
+ "id": 6879344,\r
+ "name": "content",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 0,\r
+ "width": 1280,\r
+ "height": 782\r
+ },\r
+ "nodes": [\r
+\r
+ {\r
+ "id": 6880464,\r
+ "name": "1",\r
+ "orientation": "horizontal",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 0,\r
+ "width": 1280,\r
+ "height": 782\r
+ },\r
+ "floating_nodes": [],\r
+ "nodes": [\r
+\r
+ {\r
+ "id": 6929968,\r
+ "name": "#aa0000",\r
+ "border": "normal",\r
+ "percent": 1,\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 18,\r
+ "width": 1280,\r
+ "height": 782\r
+ }\r
+ }\r
+\r
+ ]\r
+ }\r
+\r
+ ]\r
+ },\r
+\r
+ {\r
+ "id": 6880208,\r
+ "name": "bottomdock",\r
+ "layout": "dockarea",\r
+ "orientation": "vertical",\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 782,\r
+ "width": 1280,\r
+ "height": 18\r
+ },\r
+ "nodes": [\r
+\r
+ {\r
+ "id": 6931312,\r
+ "name": "#00aa00",\r
+ "percent": 1,\r
+ "rect": {\r
+ "x": 0,\r
+ "y": 782,\r
+ "width": 1280,\r
+ "height": 18\r
+ }\r
+ }\r
+\r
+ ]\r
+ }\r
+ ]\r
+ }\r
+ ]\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_marks_reply">3.7. MARKS reply</h3>\r
+<div class="paragraph"><p>The reply consists of a single array of strings for each container that has a\r
+mark. A mark can only be set on one container, so the array is unique.\r
+The order of that array is undefined.</p></div>\r
+<div class="paragraph"><p>If no window has a mark the response will be the empty array [].</p></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_bar_config_reply">3.8. BAR_CONFIG reply</h3>\r
+<div class="paragraph"><p>This can be used by third-party workspace bars (especially i3bar, but others\r
+are free to implement compatible alternatives) to get the <tt>bar</tt> block\r
+configuration from i3.</p></div>\r
+<div class="paragraph"><p>Depending on the input, the reply is either:</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+empty input\r
+</dt>\r
+<dd>\r
+<p>\r
+ An array of configured bar IDs\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+Bar ID\r
+</dt>\r
+<dd>\r
+<p>\r
+ A JSON map containing the configuration for the specified bar.\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p>Each bar configuration has the following properties:</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+id (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The ID for this bar. Included in case you request multiple\r
+ configurations and want to differentiate the different replies.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+mode (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Either <tt>dock</tt> (the bar sets the dock window type) or <tt>hide</tt> (the bar\r
+ does not show unless a specific key is pressed).\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+position (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Either <tt>bottom</tt> or <tt>top</tt> at the moment.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+status_command (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Command which will be run to generate a statusline. Each line on stdout\r
+ of this command will be displayed in the bar. At the moment, no\r
+ formatting is supported.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+font (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The font to use for text on the bar.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+workspace_buttons (boolean)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Display workspace buttons or not? Defaults to true.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+binding_mode_indicator (boolean)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Display the mode indicator or not? Defaults to true.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+verbose (boolean)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Should the bar enable verbose output for debugging? Defaults to false.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+colors (map)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Contains key/value pairs of colors. Each value is a color code in hex,\r
+ formatted #rrggbb (like in HTML).\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p>The following colors can be configured at the moment:</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+background\r
+</dt>\r
+<dd>\r
+<p>\r
+ Background color of the bar.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+statusline\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text color to be used for the statusline.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+separator\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text color to be used for the separator.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+focused_background\r
+</dt>\r
+<dd>\r
+<p>\r
+ Background color of the bar on the currently focused monitor output.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+focused_statusline\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text color to be used for the statusline on the currently focused\r
+ monitor output.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+focused_separator\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text color to be used for the separator on the currently focused\r
+ monitor output.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+focused_workspace_text/focused_workspace_bg/focused_workspace_border\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text/background/border color for a workspace button when the workspace\r
+ has focus.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+active_workspace_text/active_workspace_bg/active_workspace_border\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text/background/border color for a workspace button when the workspace\r
+ is active (visible) on some output, but the focus is on another one.\r
+ You can only tell this apart from the focused workspace when you are\r
+ using multiple monitors.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+inactive_workspace_text/inactive_workspace_bg/inactive_workspace_border\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text/background/border color for a workspace button when the workspace\r
+ does not have focus and is not active (visible) on any output. This\r
+ will be the case for most workspaces.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+urgent_workspace_text/urgent_workspace_bg/urgent_workspace_border\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text/background/border color for workspaces which contain at least one\r
+ window with the urgency hint set.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+binding_mode_text/binding_mode_bg/binding_mode_border\r
+</dt>\r
+<dd>\r
+<p>\r
+ Text/background/border color for the binding mode indicator.\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p><strong>Example of configured bars:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>["bar-bxuqzf"]</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p><strong>Example of bar configuration:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "id": "bar-bxuqzf",\r
+ "mode": "dock",\r
+ "position": "bottom",\r
+ "status_command": "i3status",\r
+ "font": "-misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1",\r
+ "workspace_buttons": true,\r
+ "binding_mode_indicator": true,\r
+ "verbose": false,\r
+ "colors": {\r
+ "background": "#c0c0c0",\r
+ "statusline": "#00ff00",\r
+ "focused_workspace_text": "#ffffff",\r
+ "focused_workspace_bg": "#000000"\r
+ }\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_version_reply">3.9. VERSION reply</h3>\r
+<div class="paragraph"><p>The reply consists of a single JSON dictionary with the following keys:</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+major (integer)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The major version of i3, such as <tt>4</tt>.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+minor (integer)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The minor version of i3, such as <tt>2</tt>. Changes in the IPC interface (new\r
+ features) will only occur with new minor (or major) releases. However,\r
+ bugfixes might be introduced in patch releases, too.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+patch (integer)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The patch version of i3, such as <tt>1</tt> (when the complete version is\r
+ <tt>4.2.1</tt>). For versions such as <tt>4.2</tt>, patch will be set to <tt>0</tt>.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+human_readable (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ A human-readable version of i3 containing the precise git version,\r
+ build date and branch name. When you need to display the i3 version to\r
+ your users, use the human-readable version whenever possible (since\r
+ this is what <tt>i3 --version</tt> displays, too).\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+loaded_config_file_name (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The current config path.\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "human_readable" : "4.2-169-gf80b877 (2012-08-05, branch \"next\")",\r
+ "loaded_config_file_name" : "/home/hwangcc23/.i3/config",\r
+ "minor" : 2,\r
+ "patch" : 0,\r
+ "major" : 4\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_binding_modes_reply">3.10. BINDING_MODES reply</h3>\r
+<div class="paragraph"><p>The reply consists of an array of all currently configured binding modes.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>["default", "resize"]</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_config_reply">3.11. CONFIG reply</h3>\r
+<div class="paragraph"><p>The config reply is a map which currently only contains the "config" member,\r
+which is a string containing the config file as loaded by i3 most recently.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{ "config": "font pango:monospace 8\nbindsym Mod4+q exit\n" }</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_tick_reply">3.12. TICK reply</h3>\r
+<div class="paragraph"><p>The reply is a map containing the "success" member. After the reply was\r
+received, the tick event has been written to all IPC connections which subscribe\r
+to tick events. UNIX sockets are usually buffered, but you can be certain that\r
+once you receive the tick event you just triggered, you must have received all\r
+events generated prior to the <tt>SEND_TICK</tt> message (happened-before relation).</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{ "success": true }</tt></pre>\r
+</div></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_events">4. Events</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph" id="events"><p>To get informed when certain things happen in i3, clients can subscribe to\r
+events. Events consist of a name (like "workspace") and an event reply type\r
+(like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format\r
+as replies to specific commands. However, the highest bit of the message type\r
+is set to 1 to indicate that this is an event reply instead of a normal reply.</p></div>\r
+<div class="paragraph"><p>Caveat: As soon as you subscribe to an event, it is not guaranteed any longer\r
+that the requests to i3 are processed in order. This means, the following\r
+situation can happen: You send a GET_WORKSPACES request but you receive a\r
+"workspace" event before receiving the reply to GET_WORKSPACES. If your\r
+program does not want to cope which such kinds of race conditions (an\r
+event based library may not have a problem here), I suggest you create a\r
+separate connection to receive events.</p></div>\r
+<div class="sect2">\r
+<h3 id="_subscribing_to_events">4.1. Subscribing to events</h3>\r
+<div class="paragraph"><p>By sending a message of type SUBSCRIBE with a JSON-encoded array as payload\r
+you can register to an event.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>type: SUBSCRIBE\r
+payload: [ "workspace", "output" ]</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_available_events">4.2. Available events</h3>\r
+<div class="paragraph"><p>The numbers in parenthesis is the event type (keep in mind that you need to\r
+strip the highest bit first).</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+workspace (0)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when the user switches to a different workspace, when a new\r
+ workspace is initialized or when a workspace is removed (because the\r
+ last client vanished).\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+output (1)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when RandR issues a change notification (of either screens,\r
+ outputs, CRTCs or output properties).\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+mode (2)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent whenever i3 changes its binding mode.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+window (3)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when a client’s window is successfully reparented (that is when i3\r
+ has finished fitting it into a container), when a window received input\r
+ focus or when certain properties of the window have changed.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+barconfig_update (4)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when the hidden_state or mode field in the barconfig of any bar\r
+ instance was updated and when the config is reloaded.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+binding (5)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when a configured command binding is triggered with the keyboard or\r
+ mouse\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+shutdown (6)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when the ipc shuts down because of a restart or exit by user command\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+tick (7)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Sent when the ipc client subscribes to the tick event (with <tt>"first":\r
+ true</tt>) or when any ipc client sends a SEND_TICK message (with <tt>"first":\r
+ false</tt>).\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt># the appropriate 4 bytes read from the socket are stored in $input\r
+\r
+# unpack a 32-bit unsigned integer\r
+my $message_type = unpack("L", $input);\r
+\r
+# check if the highest bit is 1\r
+my $is_event = (($message_type >> 31) == 1);\r
+\r
+# use the other bits\r
+my $event_type = ($message_type & 0x7F);\r
+\r
+if ($is_event) {\r
+ say "Received event of type $event_type";\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_workspace_event">4.3. workspace event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map containing a property\r
+<tt>change (string)</tt> which indicates the type of the change ("focus", "init",\r
+"empty", "urgent", "reload", "rename", "restored", "move"). A\r
+<tt>current (object)</tt> property will be present with the affected workspace\r
+whenever the type of event affects a workspace (otherwise, it will be +null).</p></div>\r
+<div class="paragraph"><p>When the change is "focus", an <tt>old (object)</tt> property will be present with the\r
+previous workspace. When the first switch occurs (when i3 focuses the\r
+workspace visible at the beginning) there is no previous workspace, and the\r
+<tt>old</tt> property will be set to <tt>null</tt>. Also note that if the previous is empty\r
+it will get destroyed when switching, but will still be present in the "old"\r
+property.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "change": "focus",\r
+ "current": {\r
+ "id": 28489712,\r
+ "type": "workspace",\r
+ ...\r
+ }\r
+ "old": {\r
+ "id": 28489715,\r
+ "type": "workspace",\r
+ ...\r
+ }\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_output_event">4.4. output event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map containing a property\r
+<tt>change (string)</tt> which indicates the type of the change (currently only\r
+"unspecified").</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{ "change": "unspecified" }</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_mode_event">4.5. mode event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map containing a property\r
+<tt>change (string)</tt> which holds the name of current mode in use. The name\r
+is the same as specified in config when creating a mode. The default\r
+mode is simply named default. It contains a second property, <tt>pango_markup</tt>, which\r
+defines whether pango markup shall be used for displaying this mode.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "change": "default",\r
+ "pango_markup": true\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_window_event">4.6. window event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map containing a property\r
+<tt>change (string)</tt> which indicates the type of the change</p></div>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<tt>new</tt> – the window has become managed by i3\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>close</tt> – the window has closed\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>focus</tt> – the window has received input focus\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>title</tt> – the window’s title has changed\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>fullscreen_mode</tt> – the window has entered or exited fullscreen mode\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>move</tt> – the window has changed its position in the tree\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>floating</tt> – the window has transitioned to or from floating\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>urgent</tt> – the window has become urgent or lost its urgent status\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<tt>mark</tt> – a mark has been added to or removed from the window\r
+</p>\r
+</li>\r
+</ul></div>\r
+<div class="paragraph"><p>Additionally a <tt>container (object)</tt> field will be present, which consists\r
+of the window’s parent container. Be aware that for the "new" event, the\r
+container will hold the initial name of the newly reparented window (e.g.\r
+if you run urxvt with a shell that changes the title, you will still at\r
+this point get the window title as "urxvt").</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "change": "new",\r
+ "container": {\r
+ "id": 35569536,\r
+ "type": "con",\r
+ ...\r
+ }\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_barconfig_update_event">4.7. barconfig_update event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map reporting on options from the\r
+barconfig of the specified bar_id that were updated in i3. This event is the\r
+same as a <tt>GET_BAR_CONFIG</tt> reply for the bar with the given id.</p></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_binding_event">4.8. binding event</h3>\r
+<div class="paragraph"><p>This event consists of a single serialized map reporting on the details of a\r
+binding that ran a command because of user input. The <tt>change (string)</tt> field\r
+indicates what sort of binding event was triggered (right now it will always be\r
+<tt>"run"</tt> but may be expanded in the future).</p></div>\r
+<div class="paragraph"><p>The <tt>binding (object)</tt> field contains details about the binding that was run:</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+command (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The i3 command that is configured to run for this binding.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+event_state_mask (array of strings)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The group and modifier keys that were configured with this binding.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+input_code (integer)\r
+</dt>\r
+<dd>\r
+<p>\r
+ If the binding was configured with <tt>bindcode</tt>, this will be the key code\r
+ that was given for the binding. If the binding is a mouse binding, it will be\r
+ the number of the mouse button that was pressed. Otherwise it will be 0.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+symbol (string or null)\r
+</dt>\r
+<dd>\r
+<p>\r
+ If this is a keyboard binding that was configured with <tt>bindsym</tt>, this\r
+ field will contain the given symbol. Otherwise it will be <tt>null</tt>.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+input_type (string)\r
+</dt>\r
+<dd>\r
+<p>\r
+ This will be <tt>"keyboard"</tt> or <tt>"mouse"</tt> depending on whether or not this was\r
+ a keyboard or a mouse binding.\r
+</p>\r
+</dd>\r
+</dl></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "change": "run",\r
+ "binding": {\r
+ "command": "nop",\r
+ "event_state_mask": [\r
+ "shift",\r
+ "ctrl"\r
+ ],\r
+ "input_code": 0,\r
+ "symbol": "t",\r
+ "input_type": "keyboard"\r
+ }\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_shutdown_event">4.9. shutdown event</h3>\r
+<div class="paragraph"><p>This event is triggered when the connection to the ipc is about to shutdown\r
+because of a user action such as a <tt>restart</tt> or <tt>exit</tt> command. The <tt>change\r
+(string)</tt> field indicates why the ipc is shutting down. It can be either\r
+<tt>"restart"</tt> or <tt>"exit"</tt>.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "change": "restart"\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="_tick_event">4.10. tick event</h3>\r
+<div class="paragraph"><p>This event is triggered by a subscription to tick events or by a <tt>SEND_TICK</tt>\r
+message.</p></div>\r
+<div class="paragraph"><p><strong>Example (upon subscription):</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "first": true,\r
+ "payload": ""\r
+}</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p><strong>Example (upon <tt>SEND_TICK</tt> with a payload of <tt>arbitrary string</tt>):</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{\r
+ "first": false,\r
+ "payload": "arbitrary string"\r
+}</tt></pre>\r
+</div></div>\r
+</div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_see_also_existing_libraries">5. See also (existing libraries)</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph" id="libraries"><p>For some languages, libraries are available (so you don’t have to implement\r
+all this on your own). This list names some (if you wrote one, please let me\r
+know):</p></div>\r
+<div class="dlist"><dl>\r
+<dt class="hdlist1">\r
+C\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+i3 includes a headerfile <tt>i3/ipc.h</tt> which provides you all constants.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="https://github.com/acrisci/i3ipc-glib">https://github.com/acrisci/i3ipc-glib</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+C++\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/drmgc/i3ipcpp">https://github.com/drmgc/i3ipcpp</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Go\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/mdirkse/i3ipc-go">https://github.com/mdirkse/i3ipc-go</a>\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="https://github.com/i3/go-i3">https://github.com/i3/go-i3</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+JavaScript\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/acrisci/i3ipc-gjs">https://github.com/acrisci/i3ipc-gjs</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Lua\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/acrisci/i3ipc-lua">https://github.com/acrisci/i3ipc-lua</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Perl\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://metacpan.org/module/AnyEvent::I3">https://metacpan.org/module/AnyEvent::I3</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Python\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/acrisci/i3ipc-python">https://github.com/acrisci/i3ipc-python</a>\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="https://github.com/whitelynx/i3ipc">https://github.com/whitelynx/i3ipc</a> (not maintained)\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="https://github.com/ziberna/i3-py">https://github.com/ziberna/i3-py</a> (not maintained)\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Ruby\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/veelenga/i3ipc-ruby">https://github.com/veelenga/i3ipc-ruby</a>\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+<a href="https://github.com/badboy/i3-ipc">https://github.com/badboy/i3-ipc</a> (not maintained)\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+Rust\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/tmerr/i3ipc-rs">https://github.com/tmerr/i3ipc-rs</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+<dt class="hdlist1">\r
+OCaml\r
+</dt>\r
+<dd>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+<a href="https://github.com/Armael/ocaml-i3ipc">https://github.com/Armael/ocaml-i3ipc</a>\r
+</p>\r
+</li>\r
+</ul></div>\r
+</dd>\r
+</dl></div>\r
+</div>\r
+</div>\r
+<div class="sect1">\r
+<h2 id="_appendix_a_detecting_byte_order_in_memory_safe_languages">6. Appendix A: Detecting byte order in memory-safe languages</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>Some programming languages such as Go don’t offer a way to serialize data in the\r
+native byte order of the machine they’re running on without resorting to tricks\r
+involving the <tt>unsafe</tt> package.</p></div>\r
+<div class="paragraph"><p>The following technique can be used (and will not be broken by changes to i3) to\r
+detect the byte order i3 is using:</p></div>\r
+<div class="olist arabic"><ol class="arabic">\r
+<li>\r
+<p>\r
+The byte order dependent fields of an IPC message are message type and\r
+ payload length.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+The message type <tt>RUN_COMMAND</tt> (0) is the same in big and little endian, so\r
+ we can use it in either byte order to elicit a reply from i3.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+The payload length 65536 + 256 (<tt>0x00 01 01 00</tt>) is the same in big and\r
+ little endian, and also small enough to not worry about memory allocations\r
+ of that size. We must use payloads of length 65536 + 256 in every message\r
+ we send, so that i3 will be able to read the entire message regardless of\r
+ the byte order it uses.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Send a big endian encoded message of type <tt>SUBSCRIBE</tt> (2) with payload <tt>[]</tt>\r
+ followed by 65536 + 256 - 2 <tt>SPACE</tt> (ASCII 0x20) bytes.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+If i3 is running in big endian, this message is treated as a noop,\r
+ resulting in a <tt>SUBSCRIBE</tt> reply with payload <tt>{"success":true}</tt>\r
+ <span class="footnote"><br />[A small payload is important: that way, we circumvent dealing\r
+ with UNIX domain socket buffer sizes, whose size depends on the\r
+ implementation/operating system. Exhausting such a buffer results in an i3\r
+ deadlock unless you concurrently read and write, which — depending on the\r
+ programming language — makes the technique much more complicated.]<br /></span>.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If i3 is running in little endian, this message is read in its entirety due\r
+ to the byte order independent payload length, then\r
+ <a href="https://github.com/i3/i3/blob/d726d09d496577d1c337a4b97486f2c9fbc914f1/src/ipc.c#L1188">silently\r
+ discarded</a> due to the unknown message type.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Send a byte order independent message, i.e. type <tt>RUN_COMMAND</tt> (0) with\r
+ payload <tt>nop byte order detection. padding:</tt>, padded to 65536 + 256 bytes\r
+ with <tt>a</tt> (ASCII 0x61) bytes. i3 will reply to this message with a reply of\r
+ type <tt>COMMAND</tt> (0).\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+The human-readable prefix is in there to not confuse readers of the i3 log.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+This messages serves as a synchronization primitive so that we know whether\r
+ i3 discarded the <tt>SUBSCRIBE</tt> message or didn’t answer it yet.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Receive a message header from i3, decoding the message type as big endian.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+If the message’s reply type is <tt>COMMAND</tt> (0), i3 is running in little\r
+ endian (because the <tt>SUBSCRIBE</tt> message was discarded). Decode the message\r
+ payload length as little endian, receive the message payload.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If the message’s reply type is anything else, i3 is running in big endian\r
+ (because our big endian encoded <tt>SUBSCRIBE</tt> message was answered). Decode\r
+ the message payload length in big endian, receive the message\r
+ payload. Then, receive the pending <tt>COMMAND</tt> message reply in big endian.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+From here on out, send/receive all messages using the detected byte order.\r
+</p>\r
+</li>\r
+</ol></div>\r
+<div class="paragraph"><p>Find an example implementation of this technique in\r
+<a href="https://github.com/i3/go-i3/blob/master/byteorder.go">https://github.com/i3/go-i3/blob/master/byteorder.go</a></p></div>\r