windows, or toolbar windows (GIMP or similar). Those windows usually set the
appropriate hint and are opened in floating mode by default.
-You can enable floating mode for a window by pressing +mod+Shift+Space+. By
+You can toggle floating mode for a window by pressing +mod+Shift+Space+. By
dragging the window’s titlebar with your mouse you can move the window
around. By grabbing the borders and moving them you can resize the window. You
can also do that by using the <<floating_modifier>>.
*Syntax*:
---------------------------------------------
-new_window <normal|1pixel|borderless>
+new_window <normal|1pixel|none>
---------------------------------------------
*Example*:
*Syntax*:
-----------------------------
-for_window [criteria] command
+for_window <criteria> command
-----------------------------
*Examples*:
for_window [title="x200: ~/work"] floating enable
------------------------------------------------
+The valid criteria are the same as those for commands, see <<command_criteria>>.
+
=== Variables
As you learned in the section about keyboard bindings, you will have
[[assign_workspace]]
-Specific windows can be matched by window class and/or window title. It is
-recommended that you match on window classes instead of window titles whenever
-possible because some applications first create their window, and then worry
-about setting the correct title. Firefox with Vimperator comes to mind. The
-window starts up being named Firefox, and only when Vimperator is loaded does
-the title change. As i3 will get the title as soon as the application maps the
+To automatically make a specific window show up on a specific workspace, you
+can use an *assignment*. You can match windows by using any criteria,
+see <<command_criteria>>. It is recommended that you match on window classes
+(and instances, when appropriate) instead of window titles whenever possible
+because some applications first create their window, and then worry about
+setting the correct title. Firefox with Vimperator comes to mind. The window
+starts up being named Firefox, and only when Vimperator is loaded does the
+title change. As i3 will get the title as soon as the application maps the
window (mapping means actually displaying it on the screen), you’d need to have
to match on 'Firefox' in this case.
-You can prefix or suffix workspaces with a `~` to specify that matching clients
-should be put into floating mode. If you specify only a `~`, the client will
-not be put onto any workspace, but will be set floating on the current one.
-
*Syntax*:
------------------------------------------------------------
-assign ["]window class[/window title]["] [→] [workspace]
+assign <criteria> [→] workspace
------------------------------------------------------------
*Examples*:
----------------------
-assign urxvt 2
-assign urxvt → 2
-assign urxvt → work
-assign "urxvt" → 2
-assign "urxvt/VIM" → 3
-assign "gecko" → 4
+# Assign URxvt terminals to workspace 2
+assign [class="URxvt"] 2
+
+# Same thing, but more precise (exact match instead of substring)
+assign [class="^URxvt$"] 2
+
+# Same thing, but with a beautiful arrow :)
+assign [class="^URxvt$"] → 2
+
+# Assignment to a named workspace
+assign [class="^URxvt$"] → work
+
+# Start urxvt -name irssi
+assign [class="^URxvt$" instance="^irssi$"] → 3
----------------------
Note that the arrow is not required, it just looks good :-). If you decide to
use it, it has to be a UTF-8 encoded arrow, not `->` or something like that.
+To get the class and instance, you can use +xprop+. After clicking on the
+window, you will see the following output:
+
+*xwininfo*:
+-----------------------------------
+WM_CLASS(STRING) = "irssi", "URxvt"
+-----------------------------------
+
+The first part of the WM_CLASS is the instance ("irssi" in this example), the
+second part is the class ("URxvt" in this example).
+
+Should you have any problems with assignments, make sure to check the i3
+logfile first (see http://i3wm.org/docs/debugging.html). It includes more
+details about the matching process and the window’s actual class, instance and
+title when starting up.
+
=== Automatically starting applications on i3 startup
By using the +exec+ keyword outside a keybinding, you can configure
bindsym mod+x move workspace 3; workspace 3
-------------------------------------------
+[[command_criteria]]
+
Furthermore, you can change the scope of a command, that is, which containers
should be affected by that command, by using various criteria. These are
prefixed in square brackets to every command. If you want to kill all windows
*Example*:
------------------------------------
bindsym mod+x [class="Firefox"] kill
+
+# same thing, but case-insensitive
+bindsym mod+x [class="(?i)firefox"] kill
------------------------------------
The criteria which are currently implemented are:
Compares the window class (the second part of WM_CLASS)
instance::
Compares the window instance (the first part of WM_CLASS)
+window_role::
+ Compares the window role (WM_WINDOW_ROLE).
id::
Compares the X11 window ID, which you can get via +xwininfo+ for example.
title::
Compares the i3-internal container ID, which you can get via the IPC
interface. Handy for scripting.
-Note that currently all criteria are compared case-insensitive and do not
-support regular expressions. This is planned to change in the future.
+The criteria +class+, +instance+, +role+, +title+ and +mark+ are actually
+regular expressions (PCRE). See +pcresyntax(3)+ or +perldoc perlre+ for
+information on how to use them.
=== Splitting containers
workspace 1, 3, 4 and 9 and you want to cycle through them with a single key
combination.
+To move a container to another xrandr output such as +LVDS1+ or +VGA1+, you can
+use the +move output+ command followed by the name of the target output. You
+may also use +left+, +right+, +up+, +down+ instead of the xrandr output name to
+move to the the next output in the specified direction.
+
*Examples*:
-------------------------
bindsym mod+1 workspace 1
projects / i3 / i3 / blobdiff