X-Git-Url: https://git.sur5r.net/?p=i3%2Fi3;a=blobdiff_plain;f=docs%2Fuserguide;fp=docs%2Fuserguide;h=91060ab2cc6df006f4c23a80665976d0c503041b;hp=ba314af111a62493477dad54d4f030d743fdd0b4;hb=1847938d4eeba98260cc79ca45a11a134274c2ea;hpb=c54f5008395b10c046f380cc3069ff779e5d2877 diff --git a/docs/userguide b/docs/userguide index ba314af1..91060ab2 100644 --- 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 -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"] @@ -585,6 +587,16 @@ workspace_layout default|stacking|tabbed workspace_layout tabbed --------------------- +=== Window title alignment + +This option determines the window title's text alignment. +Default is +left+ + +*Syntax*: +--------------------------------------------- +title_align left|center|right +--------------------------------------------- + === Default border style for new windows This option determines which border style new windows will have. The default is @@ -730,7 +742,8 @@ 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 +assign its value to the specified variable. This is done verbatim and the value +must therefore be in the format that i3 uses. A fallback must be specified in case the resource cannot be loaded from the database. *Syntax*: @@ -754,14 +767,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, -see <>. 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 <>. The difference between +assign+ and ++for_window 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 @@ -887,7 +909,7 @@ the second screen and so on). *Syntax*: ------------------------------------- -workspace output +workspace output [output2]… ------------------------------------- The 'output' is the name of the RandR output you attach your screen to. On a @@ -906,12 +928,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.) +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 -workspace 5 output VGA1 +workspace 2 output primary +workspace 5 output VGA1 LVDS1 workspace "2: vim" output VGA1 --------------------------- @@ -991,7 +1016,7 @@ ipc-socket ~/.i3/i3-ipc.sock ---------------------------- You can then use the +i3-msg+ application to perform any command listed in -the next section. +<>. === Focus follows mouse @@ -1117,6 +1142,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+, … +[[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 @@ -1594,7 +1620,7 @@ bar { } ------------------------ -=== Strip workspace numbers +=== Strip workspace numbers/name Specifies whether workspace numbers should be displayed within the workspace buttons. This is useful if you want to have a named workspace that stays in @@ -1605,11 +1631,15 @@ the form "[n]:[NAME]" will display only the name. You could use this, for instance, to display Roman numerals rather than digits by naming your workspaces to "1:I", "2:II", "3:III", "4:IV", ... +When +strip_workspace_name+ is set to +yes+, any workspace that has a name of +the form "[n]:[NAME]" will display only the number. + The default is to display the full name within the workspace button. *Syntax*: ------------------------------ strip_workspace_numbers yes|no +strip_workspace_name yes|no ------------------------------ *Example*: @@ -1707,6 +1737,7 @@ bar { } -------------------------------------- +[[list_of_commands]] == List of commands Commands are what you bind to specific keypresses. You can also issue commands @@ -2025,10 +2056,13 @@ Use the +move+ command to move a container. # defaults to 10 pixels. move [ px] -# Moves the container either to a specific location -# or to the center of the screen. If 'absolute' is -# used, it is moved to the center of all outputs. -move [absolute] position [px] [px] +# Moves the container to the specified pos_x and pos_y +# coordinates on the screen. +move position [px] [px] + +# Moves the container to the center of the screen. +# If 'absolute' is used, it is moved to the center of +# all outputs. move [absolute] position center # Moves the container to the current position of the @@ -2113,8 +2147,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 -+--no-auto-back-and-forth+ to disable <> for this specific call -only. ++--no-auto-back-and-forth+ to disable <> for this +specific call only. To move containers to specific workspaces, use +move container to workspace+. @@ -2253,8 +2287,7 @@ See <> for how to move a container/workspace to a different RandR output. [[move_to_outputs]] -[[_moving_containers_workspaces_to_randr_outputs]] -=== Moving containers/workspaces to RandR 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 +VGA1+) or to a RandR output identified by a specific direction (like +left+, @@ -2313,20 +2346,21 @@ If you want to resize containers/windows using your keyboard, you can use the *Syntax*: ------------------------------------------------------- resize grow|shrink [ px [or ppt]] -resize set [px | ppt] [px | ppt] +resize set [width] [px | ppt] +resize set height [px | ppt] +resize set [width] [px | ppt] [height] [px | ppt] ------------------------------------------------------- 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). +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. -Notes about +resize set+: a value of 0 for or means "do -not resize in this direction", and resizing a tiling container by +px+ is not -implemented. +Note about +resize set+: a value of 0 for or means "do not +resize in this direction". It is recommended to define bindings for resizing in a dedicated binding mode. See <> and the example in the i3 @@ -2469,7 +2503,9 @@ To change the border of the current client, you can use +border normal+ to use t border (including window title), +border pixel 1+ to use a 1-pixel border (no window title) and +border none+ to make the client borderless. -There is also +border toggle+ which will toggle the different border styles. +There is also +border toggle+ which will toggle the different border styles. The +optional pixel argument can be used to specify the border width when switching +to the normal and pixel styles. Note that "pixel" refers to logical pixel. On HiDPI displays, a logical pixel may be represented by multiple physical pixels, so +pixel 1+ might not @@ -2477,8 +2513,8 @@ necessarily translate into a single pixel row wide border. *Syntax*: ----------------------------------------------- -border normal|pixel [] -border none|toggle +border normal|pixel|toggle [] +border none # legacy syntax, equivalent to "border pixel 1" border 1pixel