X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fuserguide;h=c051125de763e4d40e0e89a0246220f1d00520ae;hb=74a7bf31a53ccdcc1a3b43ddccca85c67888e9f4;hp=7240409c81ee81deaeeec2674caeeb0d5dd2df94;hpb=174dc389ffe840e89199b07e6d08317ebbc9f725;p=i3%2Fi3 diff --git a/docs/userguide b/docs/userguide index 7240409c..c051125d 100644 --- a/docs/userguide +++ b/docs/userguide @@ -755,14 +755,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 @@ -888,7 +897,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 @@ -907,12 +916,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 --------------------------- @@ -992,7 +1004,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 @@ -1118,6 +1130,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 @@ -1712,6 +1725,7 @@ bar { } -------------------------------------- +[[list_of_commands]] == List of commands Commands are what you bind to specific keypresses. You can also issue commands @@ -2121,8 +2135,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+. @@ -2261,8 +2275,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+, @@ -2321,20 +2334,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 @@ -2477,7 +2491,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 @@ -2485,8 +2501,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