]> git.sur5r.net Git - i3/i3/blobdiff - docs/userguide
Added new criteria 'tiling' / 'floating'. (#2481)
[i3/i3] / docs / userguide
index d0ac2ddb7184f6ec1ee326a9eccf8a600ebffdca..93c544678559991e138bd03d8a8e4ea6b9185f2a 100644 (file)
@@ -610,11 +610,13 @@ new_window pixel 3
 
 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*:
@@ -700,6 +702,38 @@ absolutely no plans to change this. If you need a more dynamic configuration
 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
 
@@ -1645,6 +1679,9 @@ bindsym $mod+x [class="Firefox" window_role="About"] kill
 
 # 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:
@@ -1687,6 +1724,10 @@ con_id::
        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
@@ -2054,6 +2095,7 @@ See <<move_to_outputs>> 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
 
 To move a container to another RandR output (addressed by names like +LVDS1+ or
@@ -2538,7 +2580,7 @@ have more than one monitor:
    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