Update userguide "Focus Parent": add the default

[i3/i3] / docs / userguide

diff --git a/docs/userguide b/docs/userguide
index a8b35f3e5c6a7992c5475bc43086405120a8977d..e413899330f8109e4e738113447cd47df2838908 100644 (file)
--- a/docs/userguide
+++ b/docs/userguide
@@ -245,9 +245,11 @@ you open a new terminal, it will open below the current one.
 
 So, how can you open a new terminal window to the *right* of the current one?
 The solution is to use +focus parent+, which will focus the +Parent Container+ of
 
 So, how can you open a new terminal window to the *right* of the current one?
 The solution is to use +focus parent+, which will focus the +Parent Container+ of

-the current +Container+. In this case, you would focus the +Vertical Split
-Container+ which is *inside* the horizontally oriented workspace. Thus, now new
-windows will be opened to the right of the +Vertical Split Container+:
+the current +Container+. In default configuration, use +$mod+a+ to navigate one 
++Container+ up the tree (you can repeat this multiple times until you get to the
++Workspace Container+. In this case, you would focus the +Vertical Split Container+
+which is *inside* the horizontally oriented workspace. Thus, now new windows will be
+opened to the right of the +Vertical Split Container+:

 
 image::tree-shot3.png["shot3",title="Focus parent, then open new terminal"]
 
 
 image::tree-shot3.png["shot3",title="Focus parent, then open new terminal"]
 


@@ -755,14 +757,23 @@ set_from_resource $black i3wm.color0 #000000
 
 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,
 
 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.
+see <<command_criteria>>. The difference between +assign+ and
++for_window <criteria> move to workspace+ is that the former will only be
+executed when the application maps the window (mapping means actually displaying
+it on the screen) but the latter will be executed whenever a window changes its
+properties to something that matches the specified criteria.
+
+Thus, 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, you’d need to have to
+match on 'Firefox' in this case.
+Another known issue is with Spotify, which doesn't set the class hints when
+mapping the window, meaning you'll have to use a +for_window+ rule to assign
+Spotify to a specific workspace.
+Finally, using +assign [tiling]+ and +assign [floating]+ is not supported.

 
 You can also assign a window to show up on a specific output. You can use RandR
 names such as +VGA1+ or names relative to the output with the currently focused
 
 You can also assign a window to show up on a specific output. You can use RandR
 names such as +VGA1+ or names relative to the output with the currently focused


@@ -888,7 +899,7 @@ the second screen and so on).
 
 *Syntax*:
 -------------------------------------
 
 *Syntax*:
 -------------------------------------

-workspace <workspace> output <output>
+workspace <workspace> output <output1> [output2]…

 -------------------------------------
 
 The 'output' is the name of the RandR output you attach your screen to. On a
 -------------------------------------
 
 The 'output' is the name of the RandR output you attach your screen to. On a


@@ -907,12 +918,15 @@ monitor name is “Dell UP2414Q”.
 entire monitor, i3 will still use the entire area of the containing monitor
 rather than that of just the output's.)
 
 entire monitor, i3 will still use the entire area of the containing monitor
 rather than that of just the output's.)
 

+You can specify multiple outputs. The first available will be used.
+

 If you use named workspaces, they must be quoted:
 
 *Examples*:
 ---------------------------
 workspace 1 output LVDS1
 If you use named workspaces, they must be quoted:
 
 *Examples*:
 ---------------------------
 workspace 1 output LVDS1

-workspace 5 output VGA1
+workspace 2 output primary
+workspace 5 output VGA1 LVDS1

 workspace "2: vim" output VGA1
 ---------------------------
 
 workspace "2: vim" output VGA1
 ---------------------------
 


@@ -992,7 +1006,7 @@ ipc-socket ~/.i3/i3-ipc.sock
 ----------------------------
 
 You can then use the +i3-msg+ application to perform any command listed in
 ----------------------------
 
 You can then use the +i3-msg+ application to perform any command listed in

-the next section.
+<<list_of_commands>>.

 
 === Focus follows mouse
 
 
 === Focus follows mouse
 


@@ -1118,6 +1132,7 @@ force_xinerama yes
 Also note that your output names are not descriptive (like +HDMI1+) when using
 Xinerama, instead they are counted up, starting at 0: +xinerama-0+, +xinerama-1+, …
 
 Also note that your output names are not descriptive (like +HDMI1+) when using
 Xinerama, instead they are counted up, starting at 0: +xinerama-0+, +xinerama-1+, …
 

+[[workspace_auto_back_and_forth]]

 === Automatic back-and-forth when switching to the current workspace
 
 This configuration directive enables automatic +workspace back_and_forth+ (see
 === Automatic back-and-forth when switching to the current workspace
 
 This configuration directive enables automatic +workspace back_and_forth+ (see


@@ -1712,6 +1727,7 @@ bar {
 }
 --------------------------------------
 
 }
 --------------------------------------
 

+[[list_of_commands]]

 == List of commands
 
 Commands are what you bind to specific keypresses. You can also issue commands
 == List of commands
 
 Commands are what you bind to specific keypresses. You can also issue commands


@@ -2121,8 +2137,8 @@ for_window [instance=notepad] sticky enable
 
 To change to a specific workspace, use the +workspace+ command, followed by the
 number or name of the workspace. Pass the optional flag
 
 To change to a specific workspace, use the +workspace+ command, followed by the
 number or name of the workspace. Pass the optional flag

-+--no-auto-back-and-forth+ to disable <<back_and_forth>> for this specific call
-only.
++--no-auto-back-and-forth+ to disable <<workspace_auto_back_and_forth>> for this
+specific call only.

 
 To move containers to specific workspaces, use +move container to workspace+.
 
 
 To move containers to specific workspaces, use +move container to workspace+.
 


@@ -2326,16 +2342,15 @@ resize set [width] <width> [px | ppt] [height] <height> [px | ppt]
 -------------------------------------------------------
 
 Direction can either be one of +up+, +down+, +left+ or +right+. Or you can be
 -------------------------------------------------------
 
 Direction can either be one of +up+, +down+, +left+ or +right+. Or you can be

-less specific and use +width+ or +height+, in which case i3 will take/give
-space from all the other containers. The optional pixel argument specifies by
-how many pixels a *floating container* should be grown or shrunk (the default
-is 10 pixels). The ppt argument means percentage points and specifies by how
-many percentage points a *tiling container* should be grown or shrunk (the
-default is 10 percentage points).
-
-Notes about +resize set+: a value of 0 for <width> or <height> means "do
-not resize in this direction", and resizing a tiling container by +px+ is not
-implemented.
+less specific and use +width+ or +height+, in which case i3 will take/give space
+from all the other containers. The optional pixel argument specifies by how many
+pixels a container should be grown or shrunk (the default is 10 pixels). The
+optional ppt argument means "percentage points", and if specified it indicates
+that a *tiling container* should be grown or shrunk by that many points, instead
+of by the +px+ value.
+
+Note about +resize set+: a value of 0 for <width> or <height> means "do not
+resize in this direction".

 
 It is recommended to define bindings for resizing in a dedicated binding mode.
 See <<binding_modes>> and the example in the i3
 
 It is recommended to define bindings for resizing in a dedicated binding mode.
 See <<binding_modes>> and the example in the i3