"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\r
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
-<link rel="icon" type="image/png" href="/favicon.png">\r
+<link rel="icon" type="image/x-icon" href="/favicon.ico">\r
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 8.6.7" />\r
+<meta name="generator" content="AsciiDoc 8.6.9" />\r
<title>i3: Hacking i3: How To</title>\r
<link rel="stylesheet" href="/css/style.css" type="text/css" />\r
<link rel="stylesheet" href="/css/xhtml11.css" type="text/css" />\r
<script type="text/javascript">\r
/*<![CDATA[*/\r
-window.onload = function(){asciidoc.footnotes(); asciidoc.toc(2);}\r
+document.addEventListener("DOMContentLoaded", function(){asciidoc.footnotes(); asciidoc.toc(2);}, false);\r
/*]]>*/\r
</script>\r
<script type="text/javascript" src="/js/asciidoc-xhtml11.js"></script>\r
<ul id="nav">\r
<li><a style="border-bottom: 2px solid #fff" href="/docs">Docs</a></li>\r
<li><a href="/screenshots">Screens</a></li>\r
+ <li><a href="https://www.reddit.com/r/i3wm/">FAQ</a></li>\r
<li><a href="/contact">Contact</a></li>\r
- <li><a href="http://bugs.i3wm.org/">Bugs</a></li>\r
+ <li><a href="https://github.com/i3/i3/issues">Bugs</a></li>\r
</ul>\r
<br style="clear: both">\r
<div id="content">\r
all, most users sooner or later tend to lay out their windows in a way which\r
corresponds to tiling or stacking mode in i3. Therefore, why not let i3 do this\r
for you? Certainly, it’s faster than you could ever do it.</p></div>\r
-<div class="paragraph"><p>The problem with most tiling window managers is that they are too unflexible.\r
+<div class="paragraph"><p>The problem with most tiling window managers is that they are too inflexible.\r
In my opinion, a window manager is just another tool, and similar to vim which\r
can edit all kinds of text files (like source code, HTML, …) and is not limited\r
to a specific file type, a window manager should not limit itself to a certain\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
-src/cfgparse.l\r
+src/config_parser.c\r
</dt>\r
<dd>\r
<p>\r
-Contains the lexer for i3’s configuration file, written for <tt>flex(1)</tt>.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-src/cfgparse.y\r
-</dt>\r
-<dd>\r
-<p>\r
-Contains the parser for i3’s configuration file, written for <tt>bison(1)</tt>.\r
+Contains a custom configuration parser. See src/command_parser.c for rationale\r
+ on why we use a custom parser.\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
-src/cmdparse.l\r
-</dt>\r
-<dd>\r
-<p>\r
-Contains the lexer for i3 commands, written for <tt>flex(1)</tt>.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-src/cmdparse.y\r
+src/command_parser.c\r
</dt>\r
<dd>\r
<p>\r
-Contains the parser for i3 commands, written for <tt>bison(1)</tt>.\r
+Contains a hand-written parser to parse commands (commands are what\r
+you bind on keys and what you can send to i3 using the IPC interface, like\r
+<em>move left</em> or <em>workspace 4</em>).\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
<dd>\r
<p>\r
Contains all functions handling the configuration file (calling the parser\r
-(src/cfgparse.y) with the correct path, switching key bindings mode).\r
+src/config_parser.c) with the correct path, switching key bindings mode).\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
+src/restore_layout.c\r
+</dt>\r
+<dd>\r
+<p>\r
+Everything for restored containers that is not pure state parsing (which can be\r
+found in load_layout.c).\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
src/sighandler.c\r
</dt>\r
<dd>\r
</p>\r
</li>\r
</ul></div>\r
-<div class="paragraph"><p>Afterwards, i3 gets the intial geometry and reparents the window (see\r
+<div class="paragraph"><p>Afterwards, i3 gets the initial geometry and reparents the window (see\r
<tt>reparent_window()</tt>) if it wasn’t already managed.</p></div>\r
<div class="paragraph"><p>Reparenting means that for each window which is reparented, a new window,\r
slightly larger than the original one, is created. The original window is then\r
<div class="sect1">\r
<h2 id="_what_happens_when_an_application_is_started">9. What happens when an application is started?</h2>\r
<div class="sectionbody">\r
-<div class="paragraph"><p>i3 does not care for applications. All it notices is when new windows are\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
reparented (see section "Manage windows").</p></div>\r
<div class="paragraph"><p>After reparenting the window, <tt>render_tree()</tt> is called which renders the\r
<div class="sect1">\r
<h2 id="_net_wm_state">10. _NET_WM_STATE</h2>\r
<div class="sectionbody">\r
-<div class="paragraph"><p>Only the _NET_WM_STATE_FULLSCREEN atom is handled. It calls\r
-“toggle_fullscreen()” for the specific client which just configures the\r
-client to use the whole screen on which it currently is. Also, it is set as\r
-fullscreen_client for the i3Screen.</p></div>\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 class="paragraph"><p>The former calls “toggle_fullscreen()” for the specific client which just\r
+configures the client to use the whole screen on which it currently is.\r
+Also, it is set as fullscreen_client for the i3Screen.</p></div>\r
+<div class="paragraph"><p>The latter is used to set, read and display urgency hints.</p></div>\r
</div>\r
</div>\r
<div class="sect1">\r
</div>\r
<div class="sect3">\r
<h4 id="_dock_area_layout">14.3.4. Dock area layout</h4>\r
-<div class="paragraph"><p>This is a special case. Users cannot chose the dock area layout, but it will be\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 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
+display a window decoration for split containers, which consists of a representation\r
+of the child container’s names.</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>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
+for user commands and 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
+<tt>parser-specs/*.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
<pre><tt># workspace next|prev|next_on_output|prev_on_output\r
# workspace back_and_forth\r
# workspace <name>\r
+# workspace number <number>\r
state WORKSPACE:\r
direction = 'next_on_output', 'prev_on_output', 'next', 'prev'\r
-> call cmd_workspace($direction)\r
'back_and_forth'\r
-> call cmd_workspace_back_and_forth()\r
+ 'number'\r
+ -> WORKSPACE_NUMBER\r
workspace = string\r
-> call cmd_workspace_name($workspace)</tt></pre>\r
</div></div>\r
(matches the end of the input).\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+workspace number <number>\r
+</dt>\r
+<dd>\r
+<p>\r
+ The workspace command has to be followed by the keyword <tt>number</tt>. It\r
+ then transitions into the state <tt>WORKSPACE_NUMBER</tt>, where the actual\r
+ parameter will be read.\r
+</p>\r
+</dd>\r
</dl></div>\r
</div>\r
<div class="sect2">\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://www.spheredev.org/wiki/Git_for_the_lazy">http://www.spheredev.org/wiki/Git_for_the_lazy</a> or, for more documentation, see\r
-<a href="http://git-scm.com/documentation">http://git-scm.com/documentation</a></p></div>\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. There are a few things which we don’t want to see in i3, e.g. a\r
-command which will focus windows in an alt+tab like way.</p></div>\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 bugreport at <a href="http://bugs.i3wm.org/">http://bugs.i3wm.org/</a>. In case there is no\r
-bugreport yet, please create one.</p></div>\r
-<div class="paragraph"><p>After you are done, please submit your work for review at <a href="http://cr.i3wm.org/">http://cr.i3wm.org/</a></p></div>\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="http://cr.i3wm.org/">http://cr.i3wm.org/</a>. In order to make your review go as fast as possible, you\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>\r
</div>\r
<div class="sect1">\r
<h2 id="_thought_experiments">21. Thought experiments</h2>\r
gets started in any way) and the window(s) which appear.</p></div>\r
<div class="paragraph"><p>Imagine for example using dmenu: The user starts dmenu by pressing Mod+d, dmenu\r
gets started with PID 3390. The user then decides to launch Firefox, which\r
-takes a long time. So he enters firefox into dmenu and presses enter. Firefox\r
+takes a long time. So they enter firefox into dmenu and press enter. Firefox\r
gets started with PID 4001. When it finally finishes loading, it creates an X11\r
window and uses MapWindow to make it visible. This is the first time i3\r
actually gets in touch with Firefox. It decides to map the window, but it has\r
projects / i3 / i3.github.io / blobdiff