something to us to get your bug fixed. If you have any questions about the
process and/or need further help, do not hesitate to contact us!
-== Verify you are using i3 ≥ 4.12
+== Verify you are using i3 ≥ 4.13
Only the latest major version of i3 is supported. To verify which version
you are running, use:
function, which was moved into its own file because it is so long.
src/util.c::
-Contains useful functions which are not really dependant on anything.
+Contains useful functions which are not really dependent on anything.
src/window.c::
Handlers to update X11 window properties like +WM_CLASS+, +_NET_WM_NAME+,
itself for the container’s children. This function actually pushes the
state, see the next paragraph.
4. If the pointer needs to be warped to a different position (for example when
- changing focus to a differnt output), it will be warped now.
+ changing focus to a different output), it will be warped now.
5. The eventmask is restored for all mapped windows.
6. Window decorations will be rendered by calling +x_deco_recurse+ on the root
container, which then recursively calls itself for the children.
Afterwards, +con_focus+ will be called to fix the focus stack and the tree will
be flattened.
-=== Case 3: Moving to non-existant top/bottom
+=== Case 3: Moving to non-existent top/bottom
Like in case 1, the reference layout for this case is a single workspace in
horizontal orientation with two containers on it. Focus is on the left
Now, +con_focus+ will be called to fix the focus stack and the tree will be
flattened.
-=== Case 4: Moving to existant top/bottom
+=== Case 4: Moving to existent top/bottom
The reference layout for this case is a vertical workspace with two containers.
The bottom one is a h-split containing two containers (1 and 2). Focus is on
This document explains the protocol in which i3bar expects its input. It
provides support for colors, urgency, shortening and easy manipulation.
-== Rationale for chosing JSON
+== Rationale for choosing JSON
Before describing the protocol, let’s cover why JSON is a building block of
this protocol.
processing.
The default value (if none is specified) is SIGCONT.
click_events::
- If specified and true i3bar will write a infinite array (same as above)
+ If specified and true i3bar will write an infinite array (same as above)
to your stdin.
=== Blocks in detail
instance::
Instance of the block, if set
x, y::
- X11 root window coordinates where the click occured
+ X11 root window coordinates where the click occurred
button::
X11 button ID (for example 1 to 3 for left/middle/right mouse button)
GET_VERSION (7)::
Gets the version of i3. The reply will be a JSON-encoded dictionary
with the major, minor, patch and human-readable version.
+GET_BINDING_MODES (8)::
+ Gets a list of currently configured binding modes.
So, a typical message could look like this:
--------------------------------------------------
Reply to the GET_BAR_CONFIG message.
VERSION (7)::
Reply to the GET_VERSION message.
+BINDING_MODES (8)::
+ Reply to the GET_BINDING_MODES message.
=== COMMAND reply
Type of this container. Can be one of "root", "output", "con",
"floating_con", "workspace" or "dockarea".
border (string)::
- Can be either "normal", "none" or "1pixel", dependending on the
+ Can be either "normal", "none" or "pixel", depending on the
container’s border style.
current_border_width (integer)::
Number of pixels of the border width.
}
-------------------
+=== BINDING_MODES reply
+
+The reply consists of an array of all currently configured binding modes.
+
+*Example:*
+---------------------
+["default", "resize"]
+---------------------
+
== Events
[[events]]
This event consists of a single serialized map containing a property
+change (string)+ which indicates the type of the change
-* +new+ - the window has become managed by i3
-* +close+ - the window has closed
-* +focus+ - the window has received input focus
-* +title+ - the window's title has changed
-* +fullscreen_mode+ - the window has entered or exited fullscreen mode
-* +move+ - the window has changed its position in the tree
-* +floating+ - the window has transitioned to or from floating
-* +urgent+ - the window has become urgent or lost its urgent status
+* +new+ – the window has become managed by i3
+* +close+ – the window has closed
+* +focus+ – the window has received input focus
+* +title+ – the window's title has changed
+* +fullscreen_mode+ – the window has entered or exited fullscreen mode
+* +move+ – the window has changed its position in the tree
+* +floating+ – the window has transitioned to or from floating
+* +urgent+ – the window has become urgent or lost its urgent status
+* +mark+ – a mark has been added to or removed from the window
Additionally a +container (object)+ field will be present, which consists
of the window's parent container. Be aware that for the "new" event, the
Xephyr will open a window where you can inspect the running test. You can run
the tests without an X session with Xvfb, such as with +xvfb-run
-./complete-run+. This will also speed up the tests signficantly especially on
+./complete-run+. This will also speed up the tests significantly especially on
machines without a powerful video card.
.Example invocation of complete-run.pl+
testsuite uses X11::XCB, a new (and quite specific to i3 at the moment) Perl
module which uses the XCB protocol description to generate Perl bindings to
X11. They work in a very similar way to libxcb (which i3 uses) and provide
-relatively high-level interfaces (objects such as +X11::XCB::Window+) aswell as
+relatively high-level interfaces (objects such as +X11::XCB::Window+) as well as
access to the low-level interface, which is very useful when testing a window
manager.
is($x->input_focus, $left->id, 'left window focused');
----------
-However, the test fails. Sometimes. Apparantly, there is a race condition in
+However, the test fails. Sometimes. Apparently, there is a race condition in
your test. If you think about it, this is because you are using two different
pieces of software: You tell i3 to update focus, i3 confirms that, and then you
ask X11 to give you the current focus. There is a certain time i3 needs to
it significantly more attractive to run the test suite more often (or at all)
during development.
-An alternative approach to using socket activation is polling for the existance
+An alternative approach to using socket activation is polling for the existence
of the IPC socket and connecting to it. While this might be slightly easier to
implement, it wastes CPU time and is considerably uglier than this solution
:). After all, +lib/SocketActivation.pm+ contains only 54 SLOC.
You can also use <<binding_modes>> to define a mode for resizing via the
keyboard. To see an example for this, look at the
-https://github.com/i3/i3/blob/next/i3.config.keycodes[default config] provided
+https://github.com/i3/i3/blob/next/etc/config.keycodes[default config] provided
by i3.
=== Restarting i3 inplace
floating windows using the mouse is to right-click on the titlebar and drag.
For resizing floating windows with your keyboard, see the resizing binding mode
-provided by the i3 https://github.com/i3/i3/blob/next/i3.config.keycodes[default config].
+provided by the i3 https://github.com/i3/i3/blob/next/etc/config.keycodes[default config].
Floating windows are always on top of tiling windows.
You can hide container borders adjacent to the screen edges using
+hide_edge_borders+. This is useful if you are using scrollbars, or do not want
-to waste even two pixels in displayspace. Default is none.
+to waste even two pixels in displayspace. The "smart" setting hides borders on
+workspaces with only one window visible, but keeps them on workspaces with
+multiple windows visible. Default is none.
*Syntax*:
-----------------------------------------------
-hide_edge_borders none|vertical|horizontal|both
+hide_edge_borders none|vertical|horizontal|both|smart
-----------------------------------------------
*Example*:
you should create a little script which generates a configuration file and run
it before starting i3 (for example in your +~/.xsession+ file).
+Also see <<xresources>> to learn how to create variables based on resources
+loaded from the X resource database.
+
+[[xresources]]
+=== X resources
+
+<<variables>> can also be created using a value configured in the X resource
+database. This is useful, for example, to avoid configuring color values within
+the i3 configuration. Instead, the values can be configured, once, in the X
+resource database to achieve an easily maintainable, consistent color theme
+across many X applications.
+
+Defining a resource will load this resource from the resource database and
+assign its value to the specified variable. A fallback must be specified in
+case the resource cannot be loaded from the database.
+
+*Syntax*:
+----------------------------------------------------
+set_from_resource $<name> <resource_name> <fallback>
+----------------------------------------------------
+
+*Example*:
+----------------------------------------------------------------------------
+# The ~/.Xresources should contain a line such as
+# *color0: #121212
+# and must be loaded properly, e.g., by using
+# xrdb ~/.Xresources
+# This value is picked up on by other applications (e.g., the URxvt terminal
+# emulator) and can be used in i3 like this:
+set_from_resource $black i3wm.color0 #000000
+----------------------------------------------------------------------------
+
[[assign_workspace]]
=== Automatically putting clients on specific workspaces
Config files support line continuation, meaning when you end a line in a
backslash character (`\`), the line-break will be ignored by the parser. This
feature can be used to create more readable configuration files.
+Commented lines are not continued.
*Examples*:
-------------------
bindsym Mod1+f \
fullscreen toggle
+
+# this line is not continued \
+bindsym Mod1+F fullscreen toggle
-------------------
== Configuring i3bar
You can configure on which output (monitor) the icons should be displayed or
you can turn off the functionality entirely.
-You can use mutliple +tray_output+ directives in your config to specify a list
+You can use multiple +tray_output+ directives in your config to specify a list
of outputs on which you want the tray to appear. The first available output in
that list as defined by the order of the directives will be used for the tray
output.
# enable floating mode and move container to workspace 4
for_window [class="^evil-app$"] floating enable, move container to workspace 4
+
+# move all floating windows to the scratchpad
+bindsym $mod+x [floating] move scratchpad
------------------------------------
The criteria which are currently implemented are:
Compares the i3-internal container ID, which you can get via the IPC
interface. Handy for scripting. Use the special value +\_\_focused__+
to match only the currently focused window.
+floating::
+ Only matches floating windows. This criterion requires no value.
+tiling::
+ Only matches tiling windows. This criterion requires no value.
The criteria +class+, +instance+, +role+, +title+, +workspace+ and +mark+ are
actually regular expressions (PCRE). See +pcresyntax(3)+ or +perldoc perlre+ for
RandR output.
[[move_to_outputs]]
+[[_moving_containers_workspaces_to_randr_outputs]]
=== Moving containers/workspaces to RandR outputs
To move a container to another RandR output (addressed by names like +LVDS1+ or
+right+, +up+ or +down+), there are two commands:
*Syntax*:
-----------------------------------------------------
-move container to output left|right|down|up|<output>
-move workspace to output left|right|down|up|<output>
-----------------------------------------------------
+------------------------------------------------------------
+move container to output left|right|down|up|current|<output>
+move workspace to output left|right|down|up|current|<output>
+------------------------------------------------------------
*Examples*:
--------------------------------------------------------
It is recommended to define bindings for resizing in a dedicated binding mode.
See <<binding_modes>> and the example in the i3
-https://github.com/i3/i3/blob/next/i3.config.keycodes[default config] for more
+https://github.com/i3/i3/blob/next/etc/config.keycodes[default config] for more
context.
*Example*:
---------------------------------------
Alternatively, if you do not want to mess with +i3-input+, you could create
-seperate bindings for a specific set of labels and then only use those labels.
+separate bindings for a specific set of labels and then only use those labels.
///////////////////////////////////////////////////////////////////
[[pango_markup]]
track of which window you put where. Thus, you can use vim-like marks to
quickly switch between windows. See <<vim_like_marks>>.
4. For information on how to move existing workspaces between monitors,
- see <<_moving_containers_workspaces_to_randr_outputs>>.
+ see <<move_to_outputs>>.
== i3 and the rest of your software world
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_verify_you_are_using_i3_4_12">1. Verify you are using i3 ≥ 4.12</h2>\r
+<h2 id="_verify_you_are_using_i3_4_13">1. Verify you are using i3 ≥ 4.13</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Only the latest major version of i3 is supported. To verify which version\r
you are running, use:</p></div>\r
</dt>\r
<dd>\r
<p>\r
-Contains useful functions which are not really dependant on anything.\r
+Contains useful functions which are not really dependent on anything.\r
</p>\r
</dd>\r
<dt class="hdlist1">\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
+ changing focus to a different output), it will be warped now.\r
</p>\r
</li>\r
<li>\r
be flattened.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_case_3_moving_to_non_existant_top_bottom">17.3. Case 3: Moving to non-existant top/bottom</h3>\r
+<h3 id="_case_3_moving_to_non_existent_top_bottom">17.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_existant_top_bottom">17.4. Case 4: Moving to existant top/bottom</h3>\r
+<h3 id="_case_4_moving_to_existent_top_bottom">17.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
</div>\r
</div>\r
<div class="sect1">\r
-<h2 id="_rationale_for_chosing_json">1. Rationale for chosing JSON</h2>\r
+<h2 id="_rationale_for_choosing_json">1. Rationale for choosing JSON</h2>\r
<div class="sectionbody">\r
<div class="paragraph"><p>Before describing the protocol, let’s cover why JSON is a building block of\r
this protocol.</p></div>\r
</dt>\r
<dd>\r
<p>\r
- If specified and true i3bar will write a infinite array (same as above)\r
+ If specified and true i3bar will write an infinite array (same as above)\r
to your stdin.\r
</p>\r
</dd>\r
</dt>\r
<dd>\r
<p>\r
- X11 root window coordinates where the click occured\r
+ X11 root window coordinates where the click occurred\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
with the major, minor, patch and human-readable version.\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+GET_BINDING_MODES (8)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Gets a list of currently configured binding modes.\r
+</p>\r
+</dd>\r
</dl></div>\r
<div class="paragraph"><p>So, a typical message could look like this:</p></div>\r
<div class="listingblock">\r
Reply to the GET_VERSION message.\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+BINDING_MODES (8)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Reply to the GET_BINDING_MODES message.\r
+</p>\r
+</dd>\r
</dl></div>\r
</div>\r
<div class="sect2">\r
</dt>\r
<dd>\r
<p>\r
- Can be either "normal", "none" or "1pixel", dependending on the\r
+ Can be either "normal", "none" or "pixel", depending on the\r
container’s border style.\r
</p>\r
</dd>\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>\r
</div>\r
<div class="sect1">\r
<div class="ulist"><ul>\r
<li>\r
<p>\r
-<tt>new</tt> - the window has become managed by i3\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>close</tt> - the window has closed\r
+<tt>focus</tt> – the window has received input focus\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>focus</tt> - the window has received input focus\r
+<tt>title</tt> – the window’s title has changed\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>title</tt> - the window’s title has changed\r
+<tt>fullscreen_mode</tt> – the window has entered or exited fullscreen mode\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>fullscreen_mode</tt> - the window has entered or exited fullscreen mode\r
+<tt>move</tt> – the window has changed its position in the tree\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>move</tt> - the window has changed its position in the tree\r
+<tt>floating</tt> – the window has transitioned to or from floating\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>floating</tt> - the window has transitioned to or from floating\r
+<tt>urgent</tt> – the window has become urgent or lost its urgent status\r
</p>\r
</li>\r
<li>\r
<p>\r
-<tt>urgent</tt> - the window has become urgent or lost its urgent status\r
+<tt>mark</tt> – a mark has been added to or removed from the window\r
</p>\r
</li>\r
</ul></div>\r
run the tests on a separate X server instance (using Xephyr).</p></div>\r
<div class="paragraph"><p>Xephyr will open a window where you can inspect the running test. You can run\r
the tests without an X session with Xvfb, such as with <tt>xvfb-run\r
-./complete-run</tt>. This will also speed up the tests signficantly especially on\r
+./complete-run</tt>. This will also speed up the tests significantly especially on\r
machines without a powerful video card.</p></div>\r
<div class="listingblock">\r
<div class="title">Example invocation of complete-run.pl+</div>\r
testsuite uses X11::XCB, a new (and quite specific to i3 at the moment) Perl\r
module which uses the XCB protocol description to generate Perl bindings to\r
X11. They work in a very similar way to libxcb (which i3 uses) and provide\r
-relatively high-level interfaces (objects such as <tt>X11::XCB::Window</tt>) aswell as\r
+relatively high-level interfaces (objects such as <tt>X11::XCB::Window</tt>) as well as\r
access to the low-level interface, which is very useful when testing a window\r
manager.</p></div>\r
</div>\r
cmd 'focus left';\r
is($x->input_focus, $left->id, 'left window focused');</tt></pre>\r
</div></div>\r
-<div class="paragraph"><p>However, the test fails. Sometimes. Apparantly, there is a race condition in\r
+<div class="paragraph"><p>However, the test fails. Sometimes. Apparently, there is a race condition in\r
your test. If you think about it, this is because you are using two different\r
pieces of software: You tell i3 to update focus, i3 confirms that, and then you\r
ask X11 to give you the current focus. There is a certain time i3 needs to\r
(72 files at the time of writing) from > 100 seconds to 16 seconds. This makes\r
it significantly more attractive to run the test suite more often (or at all)\r
during development.</p></div>\r
-<div class="paragraph"><p>An alternative approach to using socket activation is polling for the existance\r
+<div class="paragraph"><p>An alternative approach to using socket activation is polling for the existence\r
of the IPC socket and connecting to it. While this might be slightly easier to\r
implement, it wastes CPU time and is considerably uglier than this solution\r
:). After all, <tt>lib/SocketActivation.pm</tt> contains only 54 SLOC.</p></div>\r
and move it to the wanted size.</p></div>\r
<div class="paragraph"><p>You can also use <a href="#binding_modes">[binding_modes]</a> to define a mode for resizing via the\r
keyboard. To see an example for this, look at the\r
-<a href="https://github.com/i3/i3/blob/next/i3.config.keycodes">default config</a> provided\r
+<a href="https://github.com/i3/i3/blob/next/etc/config.keycodes">default config</a> provided\r
by i3.</p></div>\r
</div>\r
<div class="sect2">\r
can also do that by using the <a href="#floating_modifier">[floating_modifier]</a>. Another way to resize\r
floating windows using the mouse is to right-click on the titlebar and drag.</p></div>\r
<div class="paragraph"><p>For resizing floating windows with your keyboard, see the resizing binding mode\r
-provided by the i3 <a href="https://github.com/i3/i3/blob/next/i3.config.keycodes">default config</a>.</p></div>\r
+provided by the i3 <a href="https://github.com/i3/i3/blob/next/etc/config.keycodes">default config</a>.</p></div>\r
<div class="paragraph"><p>Floating windows are always on top of tiling windows.</p></div>\r
</div>\r
</div>\r
<h3 id="_hiding_vertical_borders">4.11. Hiding borders adjacent to the screen edges</h3>\r
<div class="paragraph"><p>You can hide container borders adjacent to the screen edges using\r
<tt>hide_edge_borders</tt>. This is useful if you are using scrollbars, or do not want\r
-to waste even two pixels in displayspace. Default is none.</p></div>\r
+to waste even two pixels in displayspace. The "smart" setting hides borders on\r
+workspaces with only one window visible, but keeps them on workspaces with\r
+multiple windows visible. Default is none.</p></div>\r
<div class="paragraph"><p><strong>Syntax</strong>:</p></div>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>hide_edge_borders none|vertical|horizontal|both</tt></pre>\r
+<pre><tt>hide_edge_borders none|vertical|horizontal|both|smart</tt></pre>\r
</div></div>\r
<div class="paragraph"><p><strong>Example</strong>:</p></div>\r
<div class="listingblock">\r
absolutely no plans to change this. If you need a more dynamic configuration\r
you should create a little script which generates a configuration file and run\r
it before starting i3 (for example in your <tt>~/.xsession</tt> file).</p></div>\r
+<div class="paragraph"><p>Also see <a href="#xresources">[xresources]</a> to learn how to create variables based on resources\r
+loaded from the X resource database.</p></div>\r
+</div>\r
+<div class="sect2">\r
+<h3 id="xresources">4.15. X resources</h3>\r
+<div class="paragraph"><p><a href="#variables">[variables]</a> can also be created using a value configured in the X resource\r
+database. This is useful, for example, to avoid configuring color values within\r
+the i3 configuration. Instead, the values can be configured, once, in the X\r
+resource database to achieve an easily maintainable, consistent color theme\r
+across many X applications.</p></div>\r
+<div class="paragraph"><p>Defining a resource will load this resource from the resource database and\r
+assign its value to the specified variable. A fallback must be specified in\r
+case the resource cannot be loaded from the database.</p></div>\r
+<div class="paragraph"><p><strong>Syntax</strong>:</p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>set_from_resource $<name> <resource_name> <fallback></tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p><strong>Example</strong>:</p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt># The ~/.Xresources should contain a line such as\r
+# *color0: #121212\r
+# and must be loaded properly, e.g., by using\r
+# xrdb ~/.Xresources\r
+# This value is picked up on by other applications (e.g., the URxvt terminal\r
+# emulator) and can be used in i3 like this:\r
+set_from_resource $black i3wm.color0 #000000</tt></pre>\r
+</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="assign_workspace">4.15. Automatically putting clients on specific workspaces</h3>\r
+<h3 id="assign_workspace">4.16. Automatically putting clients on specific workspaces</h3>\r
<div class="paragraph"><p>To automatically make a specific window show up on a specific workspace, you\r
can use an <strong>assignment</strong>. You can match windows by using any criteria,\r
see <a href="#command_criteria">[command_criteria]</a>. It is recommended that you match on window classes\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_automatically_starting_applications_on_i3_startup">4.16. Automatically starting applications on i3 startup</h3>\r
+<h3 id="_automatically_starting_applications_on_i3_startup">4.17. Automatically starting applications on i3 startup</h3>\r
<div class="paragraph"><p>By using the <tt>exec</tt> keyword outside a keybinding, you can configure\r
which commands will be performed by i3 on initial startup. <tt>exec</tt>\r
commands will not run when restarting i3, if you need a command to run\r
<div class="paragraph"><p>The flag --no-startup-id is explained in <a href="#exec">[exec]</a>.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="workspace_screen">4.17. Automatically putting workspaces on specific screens</h3>\r
+<h3 id="workspace_screen">4.18. Automatically putting workspaces on specific screens</h3>\r
<div class="paragraph"><p>If you assign clients to workspaces, it might be handy to put the\r
workspaces on specific screens. Also, the assignment of workspaces to screens\r
will determine which workspace i3 uses for a new screen when adding screens\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_changing_colors">4.18. Changing colors</h3>\r
+<h3 id="_changing_colors">4.19. Changing colors</h3>\r
<div class="paragraph"><p>You can change all colors which i3 uses to draw the window decorations.</p></div>\r
<div class="paragraph"><p><strong>Syntax</strong>:</p></div>\r
<div class="listingblock">\r
from single windows outside of a split container.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_interprocess_communication">4.19. Interprocess communication</h3>\r
+<h3 id="_interprocess_communication">4.20. Interprocess communication</h3>\r
<div class="paragraph"><p>i3 uses Unix sockets to provide an IPC interface. This allows third-party\r
programs to get information from i3, such as the current workspaces\r
(to display a workspace bar), and to control i3.</p></div>\r
the next section.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_focus_follows_mouse">4.20. Focus follows mouse</h3>\r
+<h3 id="_focus_follows_mouse">4.21. Focus follows mouse</h3>\r
<div class="paragraph"><p>By default, window focus follows your mouse movements. However, if you have a\r
setup where your mouse usually is in your way (like a touchpad on your laptop\r
which you do not want to disable completely), you might want to disable <em>focus\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_mouse_warping">4.21. Mouse warping</h3>\r
+<h3 id="_mouse_warping">4.22. Mouse warping</h3>\r
<div class="paragraph"><p>By default, when switching focus to a window on a different output (e.g.\r
focusing a window on workspace 3 on output VGA-1, coming from workspace 2 on\r
LVDS-1), the mouse cursor is warped to the center of that window.</p></div>\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_popups_during_fullscreen_mode">4.22. Popups during fullscreen mode</h3>\r
+<h3 id="_popups_during_fullscreen_mode">4.23. Popups during fullscreen mode</h3>\r
<div class="paragraph"><p>When you are in fullscreen mode, some applications still open popup windows\r
(take Xpdf for example). This is because these applications may not be aware\r
that they are in fullscreen mode (they do not check the corresponding hint).\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_focus_wrapping">4.23. Focus wrapping</h3>\r
+<h3 id="_focus_wrapping">4.24. Focus wrapping</h3>\r
<div class="paragraph"><p>When being in a tabbed or stacked container, the first container will be\r
focused when you use <tt>focus down</tt> on the last container — the focus wraps. If\r
however there is another stacked/tabbed container in that direction, focus will\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_forcing_xinerama">4.24. Forcing Xinerama</h3>\r
+<h3 id="_forcing_xinerama">4.25. Forcing Xinerama</h3>\r
<div class="paragraph"><p>As explained in-depth in <a href="http://i3wm.org/docs/multi-monitor.html">http://i3wm.org/docs/multi-monitor.html</a>, some X11\r
video drivers (especially the nVidia binary driver) only provide support for\r
Xinerama instead of RandR. In such a situation, i3 must be told to use the\r
Xinerama, instead they are counted up, starting at 0: <tt>xinerama-0</tt>, <tt>xinerama-1</tt>, …</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_automatic_back_and_forth_when_switching_to_the_current_workspace">4.25. Automatic back-and-forth when switching to the current workspace</h3>\r
+<h3 id="_automatic_back_and_forth_when_switching_to_the_current_workspace">4.26. Automatic back-and-forth when switching to the current workspace</h3>\r
<div class="paragraph"><p>This configuration directive enables automatic <tt>workspace back_and_forth</tt> (see\r
<a href="#back_and_forth">[back_and_forth]</a>) when switching to the workspace that is currently focused.</p></div>\r
<div class="paragraph"><p>For instance: Assume you are on workspace "1: www" and switch to "2: IM" using\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="_delaying_urgency_hint_reset_on_workspace_change">4.26. Delaying urgency hint reset on workspace change</h3>\r
+<h3 id="_delaying_urgency_hint_reset_on_workspace_change">4.27. Delaying urgency hint reset on workspace change</h3>\r
<div class="paragraph"><p>If an application on another workspace sets an urgency hint, switching to this\r
workspace may lead to immediate focus of the application, which also means the\r
window decoration color would be immediately reset to <tt>client.focused</tt>. This\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="focus_on_window_activation">4.27. Focus on window activation</h3>\r
+<h3 id="focus_on_window_activation">4.28. Focus on window activation</h3>\r
<div class="paragraph"><p>If a window is activated, e.g., via <tt>google-chrome www.google.com</tt>, it may request\r
to take focus. Since this may not preferable, different reactions can be configured.</p></div>\r
<div class="paragraph"><p>Note that this may not affect windows that are being opened. To prevent new windows\r
</dl></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="show_marks">4.28. Drawing marks on window decoration</h3>\r
+<h3 id="show_marks">4.29. Drawing marks on window decoration</h3>\r
<div class="paragraph"><p>If activated, marks on windows are drawn in their window decoration. However,\r
any mark starting with an underscore in its name (<tt>_</tt>) will not be drawn even if\r
this option is activated.</p></div>\r
</div></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="line_continuation">4.29. Line continuation</h3>\r
+<h3 id="line_continuation">4.30. Line continuation</h3>\r
<div class="paragraph"><p>Config files support line continuation, meaning when you end a line in a\r
backslash character (<tt>\</tt>), the line-break will be ignored by the parser. This\r
-feature can be used to create more readable configuration files.</p></div>\r
+feature can be used to create more readable configuration files.\r
+Commented lines are not continued.</p></div>\r
<div class="paragraph"><p><strong>Examples</strong>:</p></div>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>bindsym Mod1+f \\r
-fullscreen toggle</tt></pre>\r
+fullscreen toggle\r
+\r
+# this line is not continued \\r
+bindsym Mod1+F fullscreen toggle</tt></pre>\r
</div></div>\r
</div>\r
</div>\r
NetworkManager, VLC, Pidgin, etc. can place little icons.</p></div>\r
<div class="paragraph"><p>You can configure on which output (monitor) the icons should be displayed or\r
you can turn off the functionality entirely.</p></div>\r
-<div class="paragraph"><p>You can use mutliple <tt>tray_output</tt> directives in your config to specify a list\r
+<div class="paragraph"><p>You can use multiple <tt>tray_output</tt> directives in your config to specify a list\r
of outputs on which you want the tray to appear. The first available output in\r
that list as defined by the order of the directives will be used for the tray\r
output.</p></div>\r
bindsym $mod+x [class="Firefox" window_role="About"] kill\r
\r
# enable floating mode and move container to workspace 4\r
-for_window [class="^evil-app$"] floating enable, move container to workspace 4</tt></pre>\r
+for_window [class="^evil-app$"] floating enable, move container to workspace 4\r
+\r
+# move all floating windows to the scratchpad\r
+bindsym $mod+x [floating] move scratchpad</tt></pre>\r
</div></div>\r
<div class="paragraph"><p>The criteria which are currently implemented are:</p></div>\r
<div class="dlist"><dl>\r
to match only the currently focused window.\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+floating\r
+</dt>\r
+<dd>\r
+<p>\r
+ Only matches floating windows. This criterion requires no value.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+tiling\r
+</dt>\r
+<dd>\r
+<p>\r
+ Only matches tiling windows. This criterion requires no value.\r
+</p>\r
+</dd>\r
</dl></div>\r
<div class="paragraph"><p>The criteria <tt>class</tt>, <tt>instance</tt>, <tt>role</tt>, <tt>title</tt>, <tt>workspace</tt> and <tt>mark</tt> are\r
actually regular expressions (PCRE). See <tt>pcresyntax(3)</tt> or <tt>perldoc perlre</tt> for\r
RandR output.</p></div>\r
</div>\r
<div class="sect2">\r
-<h3 id="move_to_outputs">6.9. Moving containers/workspaces to RandR outputs</h3>\r
+<h3 id="_moving_containers_workspaces_to_randr_outputs">6.9. Moving containers/workspaces to RandR outputs</h3>\r
<div class="paragraph"><p>To move a container to another RandR output (addressed by names like <tt>LVDS1</tt> or\r
<tt>VGA1</tt>) or to a RandR output identified by a specific direction (like <tt>left</tt>,\r
<tt>right</tt>, <tt>up</tt> or <tt>down</tt>), there are two commands:</p></div>\r
<div class="paragraph"><p><strong>Syntax</strong>:</p></div>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>move container to output left|right|down|up|<output>\r
-move workspace to output left|right|down|up|<output></tt></pre>\r
+<pre><tt>move container to output left|right|down|up|current|<output>\r
+move workspace to output left|right|down|up|current|<output></tt></pre>\r
</div></div>\r
<div class="paragraph"><p><strong>Examples</strong>:</p></div>\r
<div class="listingblock">\r
floating containers.</p></div>\r
<div class="paragraph"><p>It is recommended to define bindings for resizing in a dedicated binding mode.\r
See <a href="#binding_modes">[binding_modes]</a> and the example in the i3\r
-<a href="https://github.com/i3/i3/blob/next/i3.config.keycodes">default config</a> for more\r
+<a href="https://github.com/i3/i3/blob/next/etc/config.keycodes">default config</a> for more\r
context.</p></div>\r
<div class="paragraph"><p><strong>Example</strong>:</p></div>\r
<div class="listingblock">\r
<li>\r
<p>\r
For information on how to move existing workspaces between monitors,\r
- see <a href="#_moving_containers_workspaces_to_randr_outputs">[_moving_containers_workspaces_to_randr_outputs]</a>.\r
+ see <a href="#move_to_outputs">[move_to_outputs]</a>.\r
</p>\r
</li>\r
</ol></div>\r
projects / i3 / i3.github.io / commitdiff