From: Michael Stapelberg Date: Sun, 31 Jul 2011 23:25:23 +0000 (+0200) Subject: add (versioned) docs for 4.0 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=2432814759f5b1409999c7ff458d0c876e633044;p=i3%2Fi3.github.io add (versioned) docs for 4.0 --- diff --git a/_docs/Makefile b/_docs/Makefile index b94e0eb..7def7e4 100644 --- a/_docs/Makefile +++ b/_docs/Makefile @@ -1,5 +1,5 @@ -all: hacking-howto.html debugging.html repositories.html userguide.html ipc.html multi-monitor.html wsbar.html tree-migrating.html i3status.html i3.html +all: hacking-howto.html debugging.html repositories.html userguide.html ipc.html multi-monitor.html wsbar.html i3status.html i3.html i3-config-wizard.html i3-nagbar.html i3-migrate-config-to-v4.html i3-msg.html hacking-howto.html: hacking-howto asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< @@ -13,9 +13,6 @@ repositories.html: repositories userguide.html: userguide asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< -tree-migrating.html: tree-migrating - asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< - ipc.html: ipc asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< @@ -28,7 +25,7 @@ wsbar.html: wsbar i3status.html: i3status.man asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< -i3.html: i3.man +%.html: %.man asciidoc -a linkcss -a stylesdir=/css -a scriptsdir=/js --backend=xhtml11 -f conf/i3html.conf -a toc -n $< clean: diff --git a/_docs/debugging b/_docs/debugging index d52edea..5e71ecf 100644 --- a/_docs/debugging +++ b/_docs/debugging @@ -1,7 +1,7 @@ Debugging i3: How To ==================== Michael Stapelberg -March 2010 +July 2011 This document describes how to debug i3 suitably for sending us useful bug reports, even if you have no clue of C programming. @@ -12,14 +12,21 @@ debugging and/or need further help, do not hesitate to contact us! == Enabling logging -i3 spits out much information onto stdout, if told so. To have a clearly -defined place where log files will be saved, you should redirect stdout and -stderr in xsession. While you’re at it, putting each run of i3 in a separate -log file with date/time in it is a good idea to not get confused about the -different log files later on. +i3 logs useful information to stdout. To have a clearly defined place where log +files will be saved, you should redirect stdout and stderr in your ++~/.xsession+. While you’re at it, putting each run of i3 in a separate log +file with date/time in its filename is a good idea to not get confused about +the different log files later on. -------------------------------------------------------------------- -exec /usr/bin/i3 -V -d all >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1 +exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 +-------------------------------------------------------------------- + +To enable verbose output and all levels of debug output (required when +attaching logfiles to bugreports), add the parameters +-V -d all+, like this: + +-------------------------------------------------------------------- +exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 -------------------------------------------------------------------- == Enabling core dumps @@ -29,7 +36,7 @@ of the memory of the i3 process which can be loaded into a debugger). To get a core dump, you have to make sure that the user limit for core dump files is set high enough. Many systems ship with a default value which even forbids core dumps completely. To disable the limit completely and thus enable core dumps, -use the following command (in your .xsession, before starting i3): +use the following command (in your +~/.xsession+, before starting i3): ------------------- ulimit -c unlimited @@ -50,9 +57,9 @@ process id (%p) in it. You can save this setting across reboots using == Compiling with debug symbols To actually get useful core dumps, you should make sure that your version of i3 -is compiled with debug symbols, that is, that they are not stripped during the -build process. You can check whether your executable contains symbols by -issuing the following command: +is compiled with debug symbols, that is, that the symbols are not stripped +during the build process. You can check whether your executable contains +symbols by issuing the following command: ---------------- file $(which i3) diff --git a/_docs/hacking-howto b/_docs/hacking-howto index dff074c..9a7ec9d 100644 --- a/_docs/hacking-howto +++ b/_docs/hacking-howto @@ -1,7 +1,7 @@ Hacking i3: How To ================== Michael Stapelberg -December 2009 +July 2011 This document is intended to be the first thing you read before looking and/or touching i3’s source code. It should contain all important information to help @@ -65,6 +65,13 @@ the layout you need at the moment. === The layout table +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// To accomplish flexible layouts, we decided to simply use a table. The table grows and shrinks as you need it. Each cell holds a container which then holds windows (see picture below). You can use different layouts for each container @@ -106,9 +113,15 @@ window). |======== Furthermore, you can freely resize table cells. +///////////////////////////////////////////////////////////////////////////////// == Files +include/atoms.xmacro:: +A file containing all X11 atoms which i3 uses. This file will be included +various times (for defining, requesting and receiving the atoms), each time +with a different definition of xmacro(). + include/data.h:: Contains data definitions used by nearly all files. You really need to read this first. @@ -128,19 +141,27 @@ src/click.c:: Contains all functions which handle mouse button clicks (right mouse button clicks initiate resizing and thus are relatively complex). -src/client.c:: -Contains all functions which are specific to a certain client (make it -fullscreen, see if its class/name matches a pattern, kill it, …). +src/cmdparse.l:: +Contains the lexer for i3 commands, written for +flex(1)+. + +src/cmdparse.y:: +Contains the parser for i3 commands, written for +bison(1)+. -src/commands.c:: -Parsing commands and actually executing them (focusing, moving, …). +src/con.c:: +Contains all functions which deal with containers directly (creating +containers, searching containers, getting specific properties from containers, +…). src/config.c:: -Parses the configuration file. +Contains all functions handling the configuration file (calling the parser +(src/cfgparse.y) with the correct path, switching key bindings mode). src/debug.c:: Contains debugging functions to print unhandled X events. +src/ewmh.c:: +iFunctions to get/set certain EWMH properties easily. + src/floating.c:: Contains functions for floating mode (mostly resizing/dragging). @@ -151,69 +172,123 @@ unmapping, key presses, button presses, …). src/ipc.c:: Contains code for the IPC interface. -src/layout.c:: -Renders your layout (screens, workspaces, containers). +src/load_layout.c:: +Contains code for loading layouts from JSON files. + +src/log.c:: +Handles the setting of loglevels, contains the logging functions. -src/mainx.c:: +src/main.c:: Initializes the window manager. src/manage.c:: Looks at existing or new windows and decides whether to manage them. If so, it reparents the window and inserts it into our data structures. +src/match.c:: +A "match" is a data structure which acts like a mask or expression to match +certain windows or not. For example, when using commands, you can specify a +command like this: [title="*Firefox*"] kill. The title member of the match +data structure will then be filled and i3 will check each window using +match_matches_window() to find the windows affected by this command. + +src/move.c:: +Contains code to move a container in a specific direction. + +src/output.c:: +Functions to handle CT_OUTPUT cons. + +src/randr.c:: +The RandR API is used to get (and re-query) the configured outputs (monitors, +…). + +src/render.c:: +Renders the tree data structure by assigning coordinates to every node. These +values will later be pushed to X11 in +src/x.c+. + src/resize.c:: -Contains the functions to resize columns/rows in the table. +Contains the functions to resize containers. + +src/sighandler.c:: +Handles +SIGSEGV+, +SIGABRT+ and +SIGFPE+ by showing a dialog that i3 crashed. +You can chose to let it dump core, to restart it in-place or to restart it +in-place but forget about the layout. -src/table.c:: -Manages the most important internal data structure, the design table. +src/tree.c:: +Contains functions which open or close containers in the tree, change focus or +cleanup ("flatten") the tree. See also +src/move.c+ for another similar +function, which was moved into its own file because it is so long. src/util.c:: Contains useful functions which are not really dependant on anything. +src/window.c:: +Handlers to update X11 window properties like +WM_CLASS+, +_NET_WM_NAME+, ++CLIENT_LEADER+, etc. + src/workspace.c:: Contains all functions related to workspaces (displaying, hiding, renaming…) +src/x.c:: +Transfers our in-memory tree (see +src/render.c+) to X11. + src/xcb.c:: Contains wrappers to use xcb more easily. +src/xcursor.c:: +XCursor functions (for cursor themes). + src/xinerama.c:: -(Re-)initializes the available screens and converts them to virtual screens -(see below). +Legacy support for Xinerama. See +src/randr.c+ for the preferred API. == Data structures +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// + See include/data.h for documented data structures. The most important ones are explained right here. image:bigpicture.png[The Big Picture] +///////////////////////////////////////////////////////////////////////////////// + So, the hierarchy is: +. *X11 root window*, the root container . *Virtual screens* (Screen 0 in this example) -. *Workspaces* (Workspace 1 in this example) -. *Table* (There can only be one table per Workspace) -. *Container* (left and right in this example) -. *Client* (The two clients in the left container) +. *Content container* (there are also containers for dock windows) +. *Workspaces* (Workspace 1 in this example, with horizontal orientation) +. *Split container* (vertically split) +. *X11 window containers* + +The data type is +Con+, in all cases. === Virtual screens -A virtual screen (type `i3Screen`) is generated from the connected screens -obtained through Xinerama. The difference to the raw Xinerama monitors as seen +A virtual screen (type `i3Screen`) is generated from the connected outputs +obtained through RandR. The difference to the raw RandR outputs as seen when using +xrandr(1)+ is that it falls back to the lowest common resolution of -the logical screens. +the actual enabled outputs. -For example, if your notebook has 1280x800 and you connect a video projector -with 1024x768, set up in clone mode (+xrandr \--output VGA \--mode 1024x768 -\--same-as LVDS+), i3 will have one virtual screen. +For example, if your notebook has a screen resolution of 1280x800 px and you +connect a video projector with a resolution of 1024x768 px, set it up in clone +mode (+xrandr \--output VGA1 \--mode 1024x768 \--same-as LVDS1+), i3 will have +one virtual screen. -However, if you configure it using +xrandr \--output VGA \--mode 1024x768 -\--right-of LVDS+, i3 will generate two virtual screens. For each virtual +However, if you configure it using +xrandr \--output VGA1 \--mode 1024x768 +\--right-of LVDS1+, i3 will generate two virtual screens. For each virtual screen, a new workspace will be assigned. New workspaces are created on the screen you are currently on. === Workspace -A workspace is identified by its number. Basically, you could think of +A workspace is identified by its name. Basically, you could think of workspaces as different desks in your office, if you like the desktop methaphor. They just contain different sets of windows and are completely separate of each other. Other window managers also call this ``Virtual @@ -221,18 +296,38 @@ desktops''. === The layout table +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// + Each workspace has a table, which is just a two-dimensional dynamic array containing Containers (see below). This table grows and shrinks as you need it (by moving windows to the right you can create a new column in the table, by moving them to the bottom you create a new row). +///////////////////////////////////////////////////////////////////////////////// + === Container +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// + A container is the content of a table’s cell. It holds an arbitrary amount of windows and has a specific layout (default layout, stack layout or tabbed layout). Containers can consume multiple table cells by modifying their colspan/rowspan attribute. +///////////////////////////////////////////////////////////////////////////////// + === Client A client is x11-speak for a window. @@ -244,11 +339,11 @@ ensure that the operating system on which i3 is compiled has all the expected features, i3 comes with `include/queue.h`. On BSD systems, you can use man `queue(3)`. On Linux, you have to use google (or read the source). -The lists used are `SLIST` (single linked lists), `CIRCLEQ` (circular -queues) and TAILQ (tail queues). Usually, only forward traversal is necessary, +The lists used are +SLIST+ (single linked lists), +CIRCLEQ+ (circular +queues) and +TAILQ+ (tail queues). Usually, only forward traversal is necessary, so an `SLIST` works fine. If inserting elements at arbitrary positions or at -the end of a list is necessary, a `TAILQ` is used instead. However, for the -windows inside a container, a `CIRCLEQ` is necessary to go from the currently +the end of a list is necessary, a +TAILQ+ is used instead. However, for the +windows inside a container, a +CIRCLEQ+ is necessary to go from the currently selected window to the window above/below. == Naming conventions @@ -258,14 +353,14 @@ should be chosen for those: * ``conn'' is the xcb_connection_t * ``event'' is the event of the particular type - * ``container'' names a container - * ``client'' names a client, for example when using a +CIRCLEQ_FOREACH+ + * ``con'' names a container + * ``current'' is a loop variable when using +TAILQ_FOREACH+ etc. == Startup (src/mainx.c, main()) * Establish the xcb connection - * Check for XKB extension on the separate X connection - * Check for Xinerama screens + * Check for XKB extension on the separate X connection, load Xcursor + * Check for RandR screens (with a fall-back to Xinerama) * Grab the keycodes for which bindings exist * Manage all existing windows * Enter the event loop @@ -303,9 +398,10 @@ the correct state. Then, it looks through all bindings and gets the one which matches the received event. -The bound command is parsed directly in command mode. +The bound command is parsed by the cmdparse lexer/parser, see +parse_cmd+ in ++src/cmdparse.y+. -== Manage windows (src/mainx.c, manage_window() and reparent_window()) +== Manage windows (src/main.c, manage_window() and reparent_window()) `manage_window()` does some checks to decide whether the window should be managed at all: @@ -325,7 +421,7 @@ After reparenting, the window type (`_NET_WM_WINDOW_TYPE`) is checked to see whether this window is a dock (`_NET_WM_WINDOW_TYPE_DOCK`), like dzen2 for example. Docks are handled differently, they don’t have decorations and are not assigned to a specific container. Instead, they are positioned at the bottom -of the screen. To get the height which needsd to be reserved for the window, +of the screen. To get the height which needs to be reserved for the window, the `_NET_WM_STRUT_PARTIAL` property is used. Furthermore, the list of assignments (to other workspaces, which may be on @@ -339,7 +435,7 @@ i3 does not care for applications. All it notices is when new windows are mapped (see `src/handlers.c`, `handle_map_request()`). The window is then reparented (see section "Manage windows"). -After reparenting the window, `render_layout()` is called which renders the +After reparenting the window, `render_tree()` is called which renders the internal layout table. The new window has been placed in the currently focused container and therefore the new window and the old windows (if any) need to be moved/resized so that the currently active layout (default/stacking/tabbed mode) @@ -388,6 +484,15 @@ src/layout.c, function resize_client(). == Rendering (src/layout.c, render_layout() and render_container()) +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// + + There are several entry points to rendering: `render_layout()`, `render_workspace()` and `render_container()`. The former one calls `render_workspace()` for every screen, which in turn will call @@ -460,7 +565,18 @@ floating windows: * The new width_factor for each involved column (respectively row) will be calculated. -== User commands / commandmode (src/commands.c) +///////////////////////////////////////////////////////////////////////////////// + +== User commands / commandmode (src/cmdparse.{l,y}) + +********************************************************************************* +This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff *NOW* :). +********************************************************************************* + +///////////////////////////////////////////////////////////////////////////////// + Like in vim, you can control i3 using commands. They are intended to be a powerful alternative to lots of shortcuts, because they can be combined. There @@ -485,6 +601,148 @@ j, k and l, like in vim (h = left, j = down, k = up, l = right). When you just specify the direction keys, i3 will move the focus in that direction. You can provide "m" or "s" before the direction to move a window respectively or snap. +///////////////////////////////////////////////////////////////////////////////// + +== Moving containers + +The movement code is pretty delicate. You need to consider all cases before +making any changes or before being able to fully understand how it works. + +=== Case 1: Moving inside the same container + +The reference layout for this case is a single workspace in horizontal +orientation with two containers on it. Focus is on the left container (1). + + +[width="15%",cols="^,^"] +|======== +| 1 | 2 +|======== + +When moving the left window to the right (command +move right+), tree_move will +look for a container with horizontal orientation and finds the parent of the +left container, that is, the workspace. Afterwards, it runs the code branch +commented with "the easy case": it calls TAILQ_NEXT to get the container right +of the current one and swaps both containers. + +=== Case 2: Move a container into a split container + +The reference layout for this case is a horizontal workspace with two +containers. The right container is a v-split with two containers. Focus is on +the left container (1). + +[width="15%",cols="^,^"] +|======== +1.2+^.^| 1 | 2 +| 3 +|======== + +When moving to the right (command +move right+), i3 will work like in case 1 +("the easy case"). However, as the right container is not a leaf container, but +a v-split, the left container (1) will be inserted at the right position (below +2, assuming that 2 is focused inside the v-split) by calling +insert_con_into+. + ++insert_con_into+ detaches the container from its parent and inserts it +before/after the given target container. Afterwards, the on_remove_child +callback is called on the old parent container which will then be closed, if +empty. + +Afterwards, +con_focus+ will be called to fix the focus stack and the tree will +be flattened. + +=== Case 3: Moving to non-existant top/bottom + +Like in case 1, the reference layout for this case is a single workspace in +horizontal orientation with two containers on it. Focus is on the left +container: + +[width="15%",cols="^,^"] +|======== +| 1 | 2 +|======== + +This time however, the command is +move up+ or +move down+. tree_move will look +for a container with vertical orientation. As it will not find any, ++same_orientation+ is NULL and therefore i3 will perform a forced orientation +change on the workspace by creating a new h-split container, moving the +workspace contents into it and then changing the workspace orientation to +vertical. Now it will again search for parent containers with vertical +orientation and it will find the workspace. + +This time, the easy case code path will not be run as we are not moving inside +the same container. Instead, +insert_con_into+ will be called with the focused +container and the container above/below the current one (on the level of ++same_orientation+). + +Now, +con_focus+ will be called to fix the focus stack and the tree will be +flattened. + +=== Case 4: Moving to existant top/bottom + +The reference layout for this case is a vertical workspace with two containers. +The bottom one is a h-split containing two containers (1 and 2). Focus is on +the bottom left container (1). + +[width="15%",cols="^,^"] +|======== +2+| 3 +| 1 | 2 +|======== + +This case is very much like case 3, only this time the forced workspace +orientation change does not need to be performed because the workspace already +is in vertical orientation. + +=== Case 5: Moving in one-child h-split + +The reference layout for this case is a horizontal workspace with two +containers having a v-split on the left side with a one-child h-split on the +bottom. Focus is on the bottom left container (2(h)): + +[width="15%",cols="^,^"] +|======== +| 1 1.2+^.^| 3 +| 2(h) +|======== + +In this case, +same_orientation+ will be set to the h-split container around +the focused container. However, when trying the easy case, the next/previous +container +swap+ will be NULL. Therefore, i3 will search again for a ++same_orientation+ container, this time starting from the parent of the h-split +container. + +After determining a new +same_orientation+ container (if it is NULL, the +orientation will be force-changed), this case is equivalent to case 2 or case +4. + + +=== Case 6: Floating containers + +The reference layout for this case is a horizontal workspace with two +containers plus one floating h-split container. Focus is on the floating +container. + +TODO: nice illustration. table not possible? + +When moving up/down, the container needs to leave the floating container and it +needs to be placed on the workspace (at workspace level). This is accomplished +by calling the function +attach_to_workspace+. + +== Click handling + +Without much ado, here is the list of cases which need to be considered: + +* click to focus (tiling + floating) and raise (floating) +* click to focus/raise when in stacked/tabbed mode +* floating_modifier + left mouse button to drag a floating con +* floating_modifier + right mouse button to resize a floating con +* click on decoration in a floating con to either initiate a resize (if there + is more than one child in the floating con) or to drag the + floating con (if it’s the one at the top). +* click on border in a floating con to resize the floating con +* floating_modifier + right mouse button to resize a tiling con +* click on border/decoration to resize a tiling con + == Gotchas * Forgetting to call `xcb_flush(conn);` after sending a request. This usually diff --git a/_docs/i3-config-wizard.man b/_docs/i3-config-wizard.man new file mode 100644 index 0000000..5a9ca39 --- /dev/null +++ b/_docs/i3-config-wizard.man @@ -0,0 +1,41 @@ +i3-config-wizard(1) +=================== +Michael Stapelberg +v4.0, July 2011 + +== NAME + +i3-config-wizard - creates a keysym based config based on your layout + +== SYNOPSIS + +i3-config-wizard + +== FILES + +=== /etc/i3/config.keycodes + +This file contains the default configuration with keycodes. All the bindcode +lines will be transformed to bindsym and the user-specified modifier will be +used. + +== DESCRIPTION + +i3-config-wizard is started by i3 in its default config, unless ~/.i3/config +exists. i3-config-wizard creates a keysym based i3 config file (based on +/etc/i3/config.keycodes) in ~/.i3/config. + +The advantage of using keysyms is that the config file is easy to read, +understand and modify. However, if we shipped with a keysym based default +config file, the key positions would not be consistent across different +keyboard layouts (take for example the homerow for movement). Therefore, we +ship with a keycode based default config and let the wizard transform it +according to your current keyboard layout. + +== SEE ALSO + +i3(1) + +== AUTHOR + +Michael Stapelberg and contributors diff --git a/_docs/i3-input.man b/_docs/i3-input.man new file mode 100644 index 0000000..cd85c92 --- /dev/null +++ b/_docs/i3-input.man @@ -0,0 +1,40 @@ +i3-input(1) +========= +Michael Stapelberg +v3.delta, November 2009 + +== NAME + +i3-input - interactively take a command for i3 window manager + +== SYNOPSIS + +i3-input [-s ] [-p ] [-l ] [-P ] [-f ] [-v] + +== DESCRIPTION + +i3-input is a tool to take commands (or parts of a command) composed by +the user, and send it/them to i3. This is useful, for example, for the +mark/goto command. + +== EXAMPLE + +------------------------------------------------ +i3-input -p 'mark ' -l 1 -P 'Mark: ' +------------------------------------------------ + +== ENVIRONMENT + +=== I3SOCK + +If no ipc-socket is specified on the commandline, this variable is used +to determine the path, at wich the unix domain socket is expected, on which +to connect to i3. + +== SEE ALSO + +i3(1) + +== AUTHOR + +Michael Stapelberg and contributors diff --git a/_docs/i3-migrate-config-to-v4.man b/_docs/i3-migrate-config-to-v4.man new file mode 100644 index 0000000..1d2b13f --- /dev/null +++ b/_docs/i3-migrate-config-to-v4.man @@ -0,0 +1,34 @@ +i3-migrate-config-to-v4(1) +========================== +Michael Stapelberg +v4.0, July 2011 + +== NAME + +i3-migrate-config-to-v4 - migrates your i3 config file + +== SYNOPSIS + +------------------------------------------------------- +mv ~/.i3/config ~/.i3/old.config +i3-migrate-config-to-v4 ~/.i3/old.config > ~/.i3/config +------------------------------------------------------- + +== DESCRIPTION + +i3-migrate-config-to-v4 is a Perl script which migrates your old (< version 4) +configuration files to a version 4 config file. The most significant changes +are the new commands (see the release notes). + +This script will automatically be run by i3 when it detects an old config file. +Please migrate your config file as soon as possible. We plan to include this +script in all i3 release until 2012-08-01. Afterwards, old config files will no +longer be supported. + +== SEE ALSO + +i3(1) + +== AUTHOR + +Michael Stapelberg and contributors diff --git a/_docs/i3-msg.man b/_docs/i3-msg.man new file mode 100644 index 0000000..116195b --- /dev/null +++ b/_docs/i3-msg.man @@ -0,0 +1,41 @@ +i3-msg(1) +========= +Michael Stapelberg +v3.delta, November 2009 + +== NAME + +i3-msg - send messages to i3 window manager + +== SYNOPSIS + +i3-msg "message" + +== DESCRIPTION + +i3-msg is a sample implementation for a client using the unix socket IPC +interface to i3. At the moment, it can only be used for sending commands +(like in configuration file for key bindings), but this may change in the +future (staying backwards-compatible, of course). + +== EXAMPLE + +------------------------------------------------ +i3-msg "bp" # Use 1-px border for current client +------------------------------------------------ + +== ENVIRONMENT + +=== I3SOCK + +If no ipc-socket is specified on the commandline, this variable is used +to determine the path, at wich the unix domain socket is expected, on which +to connect to i3. + +== SEE ALSO + +i3(1) + +== AUTHOR + +Michael Stapelberg and contributors diff --git a/_docs/i3-nagbar.man b/_docs/i3-nagbar.man new file mode 100644 index 0000000..3dd37bb --- /dev/null +++ b/_docs/i3-nagbar.man @@ -0,0 +1,34 @@ +i3-nagbar(1) +============ +Michael Stapelberg +v4.0, July 2011 + +== NAME + +i3-nagbar - displays an error bar on top of your screen + +== SYNOPSIS + +i3-nagbar -m 'message' -b 'label' 'action' + +== DESCRIPTION + +i3-nagbar is used by i3 to tell you about errors in your configuration file +(for example). While these errors are logged to the logfile (if any), the past +has proven that users are either not aware of their logfile or do not check it +after modifying the configuration file. + +== EXAMPLE + +------------------------------------------------ +i3-nagbar -m 'You have an error in your i3 config file!' \ +-b 'edit config' 'xterm $EDITOR ~/.i3/config' +------------------------------------------------ + +== SEE ALSO + +i3(1) + +== AUTHOR + +Michael Stapelberg and contributors diff --git a/_docs/i3.man b/_docs/i3.man index 109248e..868ff8c 100644 --- a/_docs/i3.man +++ b/_docs/i3.man @@ -1,7 +1,7 @@ i3(1) ===== Michael Stapelberg -v3.epsilon, March 2010 +v4.0, July 2011 == NAME @@ -47,7 +47,7 @@ Please be aware that i3 is primarily targeted at advanced users and developers. === IMPORTANT NOTE TO nVidia BINARY DRIVER USERS If you are using the nVidia binary graphics driver (also known as 'blob') -you need to use the +--force-xinerama+ flag (in your .xsession) when starting +you need to use the +--force-xinerama+ flag (in your ~/.xsession) when starting i3, like so: ---------------------------------------------- @@ -58,26 +58,21 @@ See also docs/multi-monitor for the full explanation. === TERMINOLOGY -Client:: -A client is X11-speak for a window. +Tree:: +i3 keeps your layout in a tree data structure. -Table:: -Your workspace is managed using a table. You can move windows around and create -new columns (move a client to the right) or rows (move it to the bottom) -implicitly. -+ -By "snapping" a client in a specific direction, you increase its colspan/rowspan. +Window:: +An X11 window, like the Firefox browser window or a terminal emulator. -Container:: -A container contains a variable number of clients. Each cell of the table is a -container. +Split container:: +A split container contains multiple other split containers or windows. + -Containers can be used in various modes. The default mode is called "default" +Containers can be used in various layouts. The default mode is called "default" and just resizes each client equally so that it fits. Workspace:: -A workspace is a set of clients (technically speaking, it’s just a table). -Other window managers call this "Virtual Desktops". +A workspace is a set of containers. Other window managers call this "Virtual +Desktops". + In i3, each workspace is assigned to a specific virtual screen. By default, screen 1 has workspace 1, screen 2 has workspace 2 and so on… However, when you @@ -103,18 +98,9 @@ on your "j" key). Alternatively, you can use the cursor keys. Mod1+:: Focus window in . -Mod3+:: -Focus container in . - Mod1+Shift+:: Move window to . -Mod3+Shift+:: -Move container to . - -Mod1+Control+:: -Snap container to . - Mod1+:: Switch to workspace . @@ -124,17 +110,21 @@ Move window to workspace . Mod1+f:: Toggle fullscreen mode. -Mod1+h:: +Mod1+s:: Enable stacking layout for the current container. Mod1+e:: Enable default layout for the current container. +Mod1+w:: +Enable tabbed layout for the current container. + Mod1+Shift+Space:: -Toggle tiling/floating for the current window. +Toggle tiling/floating for the current container. -Mod1+t:: -Select the first tiling window if the current window is floating and vice-versa. +Mod1+Space:: +Select the first tiling container if the current container is floating and +vice-versa. Mod1+Shift+q:: Kills the current window. This is equivalent to "clicking on the close button", @@ -144,8 +134,7 @@ support that, the window will be killed and it depends on the application what happens. Mod1+Shift+r:: -Restarts i3 in place (without losing any windows, but at this time, the layout -and placement of windows is not retained). +Restarts i3 in place. Your layout will be preserved. Mod1+Shift+e:: Exits i3. @@ -165,88 +154,93 @@ You can specify a custom path using the -c option. .Sample configuration ------------------------------------------------------------- +# i3 config file (v4) + +# font for window titles. ISO 10646 = Unicode font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1 -# Start terminal (Mod1+Enter) -bind Mod1+36 exec /usr/bin/urxvt +# use Mouse+Mod1 to drag floating windows to their wanted position +floating_modifier Mod1 -# Start dmenu (Mod1+v) -bind Mod1+55 exec /usr/bin/dmenu_run +# start a terminal +bindsym Mod1+Return exec /usr/bin/urxvt -# Kill current client (Mod1+Shift+q) -bind Mod1+Shift+24 kill +# kill focused window +bindsym Mod1+Shift+q kill -# Beamer on/off -bind Mod1+73 exec /home/michael/toggle_beamer.sh +# start dmenu (a program launcher) +bindsym Mod1+d exec /usr/bin/dmenu_run -# Screen locking -bind Mod1+68 exec /usr/bin/i3lock +# change focus +bindsym Mod1+j focus left +bindsym Mod1+k focus down +bindsym Mod1+l focus up +bindsym Mod1+semicolon focus right -# Restart i3 inplace (Mod1+Shift+r) -bind Mod1+Shift+27 restart +# alternatively, you can use the cursor keys: +bindsym Mod1+Left focus left +bindsym Mod1+Down focus down +bindsym Mod1+Up focus up +bindsym Mod1+Right focus right -# Exit i3 (Mod1+Shift+e) -bind Mod1+Shift+26 exit +# move focused window +bindsym Mod1+Shift+j move left +bindsym Mod1+Shift+k move down +bindsym Mod1+Shift+l move up +bindsym Mod1+Shift+semicolon move right -# Brightness -bind Mod1+97 exec sudo sh -c "echo up > /proc/acpi/ibm/brightness" -bind Mod1+103 exec sudo sh -c "echo down > /proc/acpi/ibm/brightness" +# alternatively, you can use the cursor keys: +bindsym Mod1+Shift+Left move left +bindsym Mod1+Shift+Down move down +bindsym Mod1+Shift+Up move up +bindsym Mod1+Shift+Right move right -# Fullscreen (Mod1+f) -bind Mod1+41 f +# split in horizontal orientation +bindsym Mod1+h split h -# Stacking (Mod1+h) -bind Mod1+43 s +# split in vertical orientation +bindsym Mod1+v split v -# Default (Mod1+e) -bind Mod1+26 d +# enter fullscreen mode for the focused container +bindsym Mod1+f fullscreen -# Toggle tiling/floating of the current window (Mod1+Shift+Space) -bind Mod1+Shift+65 t +# change container layout (stacked, tabbed, default) +bindsym Mod1+s layout stacking +bindsym Mod1+w layout tabbed +bindsym Mod1+e layout default -# Go into the tiling layer / floating layer, depending on whether -# the current window is tiling / floating (Mod1+t) -bind Mod1+28 focus ft +# toggle tiling / floating +bindsym Mod1+Shift+space floating toggle -# Focus (Mod1+j/k/l/;) -bind Mod1+44 h -bind Mod1+45 j -bind Mod1+46 k -bind Mod1+47 l +# change focus between tiling / floating windows +bindsym Mod1+space focus mode_toggle -# Focus Container (Mod3+j/k/l/;) -bind Mod3+44 wch -bind Mod3+45 wcj -bind Mod3+46 wck -bind Mod3+47 wcl +# focus the parent container +bindsym Mod1+a focus parent -# Snap (Mod1+Control+j/k/l/;) -bind Mod1+Control+44 sh -bind Mod1+Control+45 sj -bind Mod1+Control+46 sk -bind Mod1+Control+47 sl +# focus the child container +#bindsym Mod1+d focus child -# Move (Mod1+Shift+j/k/l/;) -bind Mod1+Shift+44 mh -bind Mod1+Shift+45 mj -bind Mod1+Shift+46 mk -bind Mod1+Shift+47 ml +# switch to workspace +bindsym Mod1+1 workspace 1 +bindsym Mod1+2 workspace 2 +# .. -# Move Container (Mod3+Shift+j/k/l/;) -bind Mod3+Shift+44 wcmh -bind Mod3+Shift+45 wcmj -bind Mod3+Shift+46 wcmk -bind Mod3+Shift+47 wcml +# move focused container to workspace +bindsym Mod1+Shift+1 move workspace 1 +bindsym Mod1+Shift+2 move workspace 2 +# ... -# Workspaces -bind Mod1+10 1 -bind Mod1+11 2 -... +# reload the configuration file +bindsym Mod1+Shift+c reload +# restart i3 inplace (preserves your layout/session, can be used to upgrade i3) +bindsym Mod1+Shift+r restart +# exit i3 (logs you out of your X session) +bindsym Mod1+Shift+e exit -# Move to Workspace -bind Mod1+Shift+10 1 -bind Mod1+Shift+11 2 -... +# Start i3bar to display a workspace bar (plus the system information i3status +# finds out, if available) +exec i3status | i3bar -d ------------------------------------------------------------- === ~/.xsession @@ -257,7 +251,7 @@ your login manager (xdm, slim, gdm, …) as soon as you login. .Sample xsession ------------------------------------------------------------- # Disable DPMS turning off the screen -xset dpms force on +xset -dpms xset s off # Disable bell @@ -294,6 +288,15 @@ echo "Starting at $(date)" >> ~/.i3/logfile exec /usr/bin/i3 -V -d all >> ~/.i3/logfile ------------------------------------------------------------- +== ENVIRONMENT + +=== I3SOCK + +This variable overwrites the IPC socket path (placed in +/tmp/i3-%u/ipc-socket.%p by default, where %u is replaced with your UNIX +username and %p is replaced with i3’s PID). The IPC socket is used by external +programs like i3-msg(1) or i3bar(1). + == TODO There is still lot of work to do. Please check our bugtracker for up-to-date @@ -308,7 +311,8 @@ and the "how to hack" guide. If you are building from source, run: You can also access these documents online at http://i3.zekjur.net/ -i3-input(1), i3-msg(1), i3-wsbar(1) +i3-input(1), i3-msg(1), i3-wsbar(1), i3-nagbar(1), i3-config-wizard(1), +i3-migrate-config-to-v4(1) == AUTHOR diff --git a/_docs/ipc b/_docs/ipc index 5db6f00..7e71326 100644 --- a/_docs/ipc +++ b/_docs/ipc @@ -10,9 +10,12 @@ workspace bar. The method of choice for IPC in our case is a unix socket because it has very little overhead on both sides and is usually available without headaches in -most languages. In the default configuration file, no ipc-socket path is -specified and thus no socket is created. The standard path (which +i3-msg+ and -+i3-input+ use) is +~/.i3/ipc.sock+. +most languages. In the default configuration file, the ipc-socket gets created +in +/tmp/i3-%u/ipc-socket.%p+ where +%u+ is your UNIX username and +%p+ is the +PID of i3. + +All i3 utilities, like +i3-msg+ and +i3-input+ will read the +I3_SOCKET_PATH+ +X11 property, stored on the X11 root window. == Establishing a connection @@ -21,7 +24,7 @@ snippet illustrates this in Perl: ------------------------------------------------------------- use IO::Socket::UNIX; -my $sock = IO::Socket::UNIX->new(Peer => '~/.i3/ipc.sock'); +my $sock = IO::Socket::UNIX->new(Peer => '/tmp/i3-ipc.sock'); ------------------------------------------------------------- == Sending messages to i3 @@ -52,6 +55,10 @@ SUBSCRIBE (2):: GET_OUTPUTS (3):: Gets the current outputs. The reply will be a JSON-encoded list of outputs (see the reply section). +GET_TREE (4):: + Gets the layout tree. i3 uses a tree as data structure which includes + every container. The reply will be the JSON-encoded tree (see the reply + section). So, a typical message could look like this: -------------------------------------------------- @@ -101,6 +108,8 @@ SUBSCRIBE (2):: Confirmation/Error code for the SUBSCRIBE message. GET_OUTPUTS (3):: Reply to the GET_OUTPUTS message. +GET_TREE (4):: + Reply to the GET_TREE message. === COMMAND reply @@ -226,6 +235,190 @@ rect (map):: ] ------------------- +=== GET_TREE reply + +The reply consists of a serialized tree. Each node in the tree (representing +one container) has at least the properties listed below. While the nodes might +have more properties, please do not use any properties which are not documented +here. They are not yet finalized and will probably change! + +id (integer):: + The internal ID (actually a C pointer value) of this container. Do not + make any assumptions about it. You can use it to (re-)identify and + address containers when talking to i3. +name (string):: + The internal name of this container. For all containers which are part + of the tree structure down to the workspace contents, this is set to a + nice human-readable name of the container. + For all other containers, the content is not defined (yet). +border (string):: + Can be either "normal", "none" or "1pixel", dependending on the + container’s border style. +layout (string):: + Can be either "default", "stacked", "tabbed", "dockarea" or "output". + Other values might be possible in the future, should we add new + layouts. +orientation (string):: + Can be either "none" (for non-split containers), "horizontal" or + "vertical". +percent (float):: + The percentage which this container takes in its parent. A value of + +null+ means that the percent property does not make sense for this + container, for example for the root container. +rect (map):: + The absolute display coordinates for this container. Display + coordinates means that when you have two 1600x1200 monitors on a single + X11 Display (the standard way), the coordinates of the first window on + the second monitor are +{ "x": 1600, "y": 0, "width": 1600, "height": + 1200 }+. +window_rect (map):: + The coordinates of the *actual client window* inside its container. + These coordinates are relative to the container and do not include the + window decoration (which is actually rendered on the parent container). + So, when using the +default+ layout, you will have a 2 pixel border on + each side, making the window_rect +{ "x": 2, "y": 0, "width": 632, + "height": 366 }+ (for example). +geometry (map):: + The original geometry the window specified when i3 mapped it. Used when + switching a window to floating mode, for example. +urgent (bool):: + Whether this container (window or workspace) has the urgency hint set. +focused (bool):: + Whether this container is currently focused. + +Please note that in the following example, I have left out some keys/values +which are not relevant for the type of the node. Otherwise, the example would +be by far too long (it already is quite long, despite showing only 1 window and +one dock window). + +It is useful to have an overview of the structure before taking a look at the +JSON dump: + +* root +** LVDS1 +*** topdock +*** content +**** workspace 1 +***** window 1 +*** bottomdock +**** dock window 1 +** VGA1 + +*Example:* +----------------------- +{ + "id": 6875648, + "name": "root", + "rect": { + "x": 0, + "y": 0, + "width": 1280, + "height": 800 + }, + "nodes": [ + + { + "id": 6878320, + "name": "LVDS1", + "layout": "output", + "rect": { + "x": 0, + "y": 0, + "width": 1280, + "height": 800 + }, + "nodes": [ + + { + "id": 6878784, + "name": "topdock", + "layout": "dockarea", + "orientation": "vertical", + "rect": { + "x": 0, + "y": 0, + "width": 1280, + "height": 0 + }, + }, + + { + "id": 6879344, + "name": "content", + "rect": { + "x": 0, + "y": 0, + "width": 1280, + "height": 782 + }, + "nodes": [ + + { + "id": 6880464, + "name": "1", + "orientation": "horizontal", + "rect": { + "x": 0, + "y": 0, + "width": 1280, + "height": 782 + }, + "floating_nodes": [], + "nodes": [ + + { + "id": 6929968, + "name": "#aa0000", + "border": "normal", + "percent": 1, + "rect": { + "x": 0, + "y": 18, + "width": 1280, + "height": 782 + } + } + + ] + } + + ] + }, + + { + "id": 6880208, + "name": "bottomdock", + "layout": "dockarea", + "orientation": "vertical", + "rect": { + "x": 0, + "y": 782, + "width": 1280, + "height": 18 + }, + "nodes": [ + + { + "id": 6931312, + "name": "#00aa00", + "percent": 1, + "rect": { + "x": 0, + "y": 782, + "width": 1280, + "height": 18 + } + } + + ] + } + ] + } + ] +} +------------------------ + + == Events [[events]] diff --git a/_docs/tree-migrating b/_docs/tree-migrating deleted file mode 100644 index 15ea54e..0000000 --- a/_docs/tree-migrating +++ /dev/null @@ -1,192 +0,0 @@ -Tree branch: Migrating -====================== -Michael Stapelberg -November 2010 - -== Introduction - -The tree branch (referring to a branch of i3 in the git repository) is the new -version of i3. Due to the very deep changes and heavy refactoring of the source -source, we decided to develop it in a seperate branch (instead of using the -next/master-branch system like before). - -== Current status - -Currently, the code is mostly working. Some of the i3 core developers have been -using the tree branch version for a few weeks now. So, if you are eager to try -out the new features and help us find bugs, give it a try! - -At the same time, a word of warning is appropriate: This version of i3 might -crash unexpectedly, so please be careful with important data (do not work for -two days without saving…). - -== Getting the latest tree branch version - -Check out the latest version: ---------------------------------------------- -$ git clone -b tree git://code.stapelberg.de/i3 ---------------------------------------------- - -Then build and install it (has the same dependencies as the latest stable i3 -version): ------------------------------ -$ cd i3 -$ make -$ sudo cp i3 /usr/bin/i3-tree ------------------------------ - -…and execute +i3-tree+ instead of +i3+ in your Xsession. - -*IMPORTANT:* Please note that configuration file compatibility is not yet done. -So, make sure you use/customize the provided +i3.config+ file. - -== Tree - -The most important change and reason for the name is that i3 stores all -information about the X11 outputs, workspaces and layout of the windows on them -in a tree. The root node is the X11 root window, followed by the X11 outputs, -then workspaces and finally the windows themselve. In previous versions of i3 -we had multiple lists (of outputs, workspaces) and a table for each workspace. -That approach turned out to be complicated to use (snapping), understand and -implement. - -=== The tree consists of Containers - -The building blocks of our tree are so called +Containers+. A +Container+ can -host a window (meaning an X11 window, one that you can actually see and use, -like a browser). Alternatively, it could contain one or more +Containers+. A -simple example is the workspace: When you start i3 with a single monitor, a -single workspace and you open two terminal windows, you will end up with a tree -like this: - -image::tree-layout2.png["layout2",float="right"] -image::tree-shot4.png["shot4",title="Two terminals on standard workspace"] - -=== Orientation and Split Containers - -[[OrientationSplit]] - -It is only natural to use so-called +Split Containers+ in order to build a -layout when using a tree as data structure. In i3, every +Container+ has an -orientation (horizontal, vertical or unspecified). So, in our example with the -workspace, the default orientation of the workspace +Container+ is horizontal -(most monitors are widescreen nowadays). If you change the orientation to -vertical (+Alt+v+ in the default config) and *then* open two terminals, i3 will -configure your windows like this: - -image::tree-shot2.png["shot2",title="Vertical Workspace Orientation"] - -An interesting new feature of the tree branch is the ability to split anything: -Let’s assume you have two terminals on a workspace (with horizontal -orientation), focus is on the right terminal. Now you want to open another -terminal window below the current one. If you would just open a new terminal -window, it would show up to the right due to the horizontal workspace -orientation. Instead, press +Alt+v+ to create a +Vertical Split Container+ (to -open a +Horizontal Split Container+, use +Alt+h+). Now you can open a new -terminal and it will open below the current one: - -image::tree-layout1.png["Layout",float="right"] -image::tree-shot1.png["shot",title="Vertical Split Container"] - -unfloat::[] - -You probably guessed it already: There is no limit on how deep your hierarchy -of splits can be. - -=== Level up - -Let’s stay with our example from above. We have a terminal on the left and two -vertically split terminals on the right, focus is on the bottom right one. When -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 +level up+, 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+: - -image::tree-shot3.png["shot3",title="Level Up, then open new terminal"] - -== Commands - -The authoritive reference for commands is +src/cmdparse.y+. You can also find -most commands in +i3.config+. Here comes a short overview over the important -commands: - -=== Manipulating layout - -------------------------------- -layout -------------------------------- - -=== Changing Focus - --------------------------- -next -prev --------------------------- - -.Examples: -------------------------- -bindsym Mod1+Left prev h -bindsym Mod1+Right next h -bindsym Mod1+Down next v -bindsym Mod1+Up prev v -------------------------- - -=== Moving - ------------------------------------------ -move ------------------------------------------ - -.Examples: ------------------------------------------ -bindsym Mod1+Shift+Left move before h -bindsym Mod1+Shift+Right move after h -bindsym Mod1+Shift+Down move before v -bindsym Mod1+Shift+Up move after v ------------------------------------------ - -=== Changing workspace - ---------------------------- -workspace ---------------------------- - -.Examples: ---------------------------- -bindsym Mod1+1 workspace 1 -bindsym Mod1+2 workspace 2 -… ---------------------------- - -=== Moving Containers to workspaces - ---------------------- -move workspace ---------------------- - -------------------------------------- -bindsym Mod1+Shift+1 move workspace 1 -bindsym Mod1+Shift+2 move workspace 2 -… -------------------------------------- - -=== Changing border style - ---------------------------- -border ---------------------------- - -=== Changing container mode - ------------------------------ -mode ------------------------------ - -== The rest - -What is not mentioned here explicitly is either unchanged and can be read in -the http://i3.zekjur.net/docs/userguide.html[i3 User’s Guide] or it is not yet -implemented. diff --git a/_docs/userguide b/_docs/userguide index 42599ca..6941af9 100644 --- a/_docs/userguide +++ b/_docs/userguide @@ -1,71 +1,72 @@ i3 User’s Guide =============== Michael Stapelberg -March 2010 +July 2011 This document contains all the information you need to configure and use the i3 -window manager. If it does not, please contact me on IRC, Jabber or E-Mail and -I’ll help you out. +window manager. If it does not, please contact us on IRC (preferred) or post your +question(s) on the mailing list. == Default keybindings For the "too long; didn’t read" people, here is an overview of the default keybindings (click to see the full size image): -*Keys to use with Mod1 (alt):* +*Keys to use with mod (alt):* -image:keyboard-layer1.png["Keys to use with Mod1 (alt)",width=600,link="keyboard-layer1.png"] +image:keyboard-layer1.png["Keys to use with mod (alt)",width=600,link="keyboard-layer1.png"] -*Keys to use with Shift+Mod1:* +*Keys to use with Shift+mod:* -image:keyboard-layer2.png["Keys to use with Shift+Mod1",width=600,link="keyboard-layer2.png"] - -As i3 uses keycodes in the default configuration, it does not matter which -keyboard layout you actually use. The key positions are what matters (of course -you can also use keysymbols, see <>). +image:keyboard-layer2.png["Keys to use with Shift+mod",width=600,link="keyboard-layer2.png"] The red keys are the modifiers you need to press (by default), the blue keys are your homerow. == Using i3 +Throughout this guide, the keyword +mod+ will be used to refer to the +configured modifier. This is the alt key (Mod1) by default, with windows (Mod4) +being a popular alternative. + === Opening terminals and moving around One very basic operation is opening a new terminal. By default, the keybinding -for this is Mod1+Enter, that is Alt+Enter in the default configuration. By -pressing Mod1+Enter, a new terminal will be opened. It will fill the whole +for this is mod+Enter, that is Alt+Enter in the default configuration. By +pressing mod+Enter, a new terminal will be opened. It will fill the whole space available on your screen. image:single_terminal.png[Single terminal] -It is important to keep in mind that i3 uses a table to manage your windows. At -the moment, you have exactly one column and one row which leaves you with one -cell. In this cell there is a container, which is where your new terminal is -opened. - -If you now open another terminal, you still have only one cell. However, the -container in that cell holds both of your terminals. So, a container is just a -group of clients with a specific layout. Containers can be resized by adjusting -the size of the cell that holds them. +If you now open another terminal, i3 will place it next to the current one, +splitting the screen size in half. Depending on your monitor, i3 will put the +created window beside the existing window (on wide displays) or below the +existing window (rotated displays). image:two_terminals.png[Two terminals] -To move the focus between the two terminals, you use the direction keys which -you may know from the editor +vi+. However, in i3, your homerow is used for -these keys (in +vi+, the keys are shifted to the left by one for compatibility -with most keyboard layouts). Therefore, +Mod1+J+ is left, +Mod1+K+ is down, -+Mod1+L+ is up and `Mod1+;` is right. So, to switch between the terminals, -use +Mod1+K+ or +Mod1+L+. +To move the focus between the two terminals, you can use the direction keys +which you may know from the editor +vi+. However, in i3, your homerow is used +for these keys (in +vi+, the keys are shifted to the left by one for +compatibility with most keyboard layouts). Therefore, +mod+J+ is left, +mod+K+ +is down, +mod+L+ is up and `mod+;` is right. So, to switch between the +terminals, use +mod+K+ or +mod+L+. Of course, you can also use the arrow keys. + +At the moment, your workspace is split (it contains two terminals) in a +specific direction (horizontal by default). Every window can be split +horizontally or vertically again, just like the workspace. The terminology is +"window" for a container that actually contains an X11 window (like a terminal +or browser) and "split container" for containers that consist of one or more +windows. -To create a new row/column (and a new cell), you can simply move a terminal (or -any other window) in the direction you want to expand your table. So, let’s -expand the table to the right by pressing `Mod1+Shift+;`. +TODO: picture of the tree -image:two_columns.png[Two columns] +To split a window vertically, press +mod+v+. To split it horizontally, press ++mod+h+. -=== Changing container modes +=== Changing the container layout -A container can have the following modes: +A split container can have one of the following layouts: default:: Windows are sized so that every window gets an equal amount of space in the @@ -77,35 +78,35 @@ tabbed:: The same principle as +stacking+, but the list of windows at the top is only a single line which is vertically split. -To switch modes, press +Mod1+e+ for default, +Mod1+h+ for stacking and -+Mod1+w+ for tabbed. +To switch modes, press +mod+e+ for default, +mod+h+ for stacking and ++mod+w+ for tabbed. image:modes.png[Container modes] === Toggling fullscreen mode for a window -To display a window fullscreen or to go out of fullscreen mode again, press -+Mod1+f+. +To display a window in fullscreen mode or to go out of fullscreen mode again, +press +mod+f+. -There is also a global fullscreen mode in i3 in which the client will use all -available outputs. To use it, or to get out of it again, press +Mod1+Shift+f+. +There is also a global fullscreen mode in i3 in which the client will span all +available outputs. === Opening other applications Aside from opening applications from a terminal, you can also use the handy -+dmenu+ which is opened by pressing +Mod1+v+ by default. Just type the name -(or a part of it) of the application which you want to open. The application -typed has to be in your +$PATH+ for this to work. ++dmenu+ which is opened by pressing +mod+d+ by default. Just type the name +(or a part of it) of the application which you want to open. The corresponding +application has to be in your +$PATH+ for this to work. Additionally, if you have applications you open very frequently, you can create a keybinding for starting the application directly. See the section -"Configuring i3" for details. +<> for details. === Closing windows If an application does not provide a mechanism for closing (most applications provide a menu, the escape key or a shortcut like +Control+W+ to close), you -can press +Mod1+Shift+q+ to kill a window. For applications which support +can press +mod+Shift+q+ to kill a window. For applications which support the WM_DELETE protocol, this will correctly close the application (saving any modifications or doing other cleanup). If the application doesn’t support the WM_DELETE protocol your X server will kill the window and the behaviour @@ -115,7 +116,7 @@ depends on the application. Workspaces are an easy way to group a set of windows. By default, you are on the first workspace, as the bar on the bottom left indicates. To switch to -another workspace, press +Mod1+num+ where +num+ is the number of the workspace +another workspace, press +mod+num+ where +num+ is the number of the workspace you want to use. If the workspace does not exist yet, it will be created. A common paradigm is to put the web browser on one workspace, communication @@ -129,18 +130,15 @@ focus to that screen. === Moving windows to workspaces -To move a window to another workspace, simply press +Mod1+Shift+num+ where +To move a window to another workspace, simply press +mod+Shift+num+ where +num+ is (like when switching workspaces) the number of the target workspace. Similarly to switching workspaces, the target workspace will be created if it does not yet exist. -=== Resizing columns/rows +=== Resizing -To resize columns or rows, just grab the border between the two columns/rows -and move it to the wanted size. Please keep in mind that each cell of the table -holds a +container+ and thus you cannot horizontally resize single windows. If -you need applications with different horizontal sizes, place them in seperate -cells one above the other. +The easiest way to resize a container is by using the mouse: Grab the border +and move it to the wanted size. See <> for how to configure i3 to be able to resize columns/rows with your keyboard. @@ -148,35 +146,21 @@ columns/rows with your keyboard. === Restarting i3 inplace To restart i3 inplace (and thus get into a clean state if there is a bug, or -to upgrade to a newer version of i3) you can use +Mod1+Shift+r+. Be aware, -though, that this kills your current layout and all the windows you have opened -will be put in a default container in only one cell. Saving layouts will be -implemented in a later version. +to upgrade to a newer version of i3) you can use +mod+Shift+r+. === Exiting i3 -To cleanly exit i3 without killing your X server, you can use +Mod1+Shift+e+. - -=== Snapping - -Snapping is a mechanism to increase/decrease the colspan/rowspan of a container. -Colspan/rowspan is the number of columns/rows a specific cell of the table -consumes. This is easier explained by giving an example, so take the following -layout: - -image:snapping.png[Snapping example] - -To use the full size of your screen, you can now snap container 3 downwards -by pressing +Mod1+Control+k+ (or snap container 2 rightwards). +To cleanly exit i3 without killing your X server, you can use +mod+Shift+e+. === Floating Floating mode is the opposite of tiling mode. The position and size of a window are not managed by i3, but by you. Using this mode violates the tiling paradigm but can be useful for some corner cases like "Save as" dialog -windows, or toolbar windows (GIMP or similar). +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 +Mod1+Shift+Space+. By +You can enable 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 <>. @@ -185,6 +169,73 @@ For resizing floating windows with your keyboard, see <>. Floating windows are always on top of tiling windows. +== Tree + +i3 stores all information about the X11 outputs, workspaces and layout of the +windows on them in a tree. The root node is the X11 root window, followed by +the X11 outputs, then dock areas and a content container, then workspaces and +finally the windows themselve. In previous versions of i3 we had multiple lists +(of outputs, workspaces) and a table for each workspace. That approach turned +out to be complicated to use (snapping), understand and implement. + +=== The tree consists of Containers + +The building blocks of our tree are so called +Containers+. A +Container+ can +host a window (meaning an X11 window, one that you can actually see and use, +like a browser). Alternatively, it could contain one or more +Containers+. A +simple example is the workspace: When you start i3 with a single monitor, a +single workspace and you open two terminal windows, you will end up with a tree +like this: + +image::tree-layout2.png["layout2",float="right"] +image::tree-shot4.png["shot4",title="Two terminals on standard workspace"] + +=== Orientation and Split Containers + +[[OrientationSplit]] + +It is only natural to use so-called +Split Containers+ in order to build a +layout when using a tree as data structure. In i3, every +Container+ has an +orientation (horizontal, vertical or unspecified). So, in our example with the +workspace, the default orientation of the workspace +Container+ is horizontal +(most monitors are widescreen nowadays). If you change the orientation to +vertical (+mod+v+ in the default config) and *then* open two terminals, i3 will +configure your windows like this: + +image::tree-shot2.png["shot2",title="Vertical Workspace Orientation"] + +An interesting new feature of the tree branch is the ability to split anything: +Let’s assume you have two terminals on a workspace (with horizontal +orientation), focus is on the right terminal. Now you want to open another +terminal window below the current one. If you would just open a new terminal +window, it would show up to the right due to the horizontal workspace +orientation. Instead, press +mod+v+ to create a +Vertical Split Container+ (to +open a +Horizontal Split Container+, use +mod+h+). Now you can open a new +terminal and it will open below the current one: + +image::tree-layout1.png["Layout",float="right"] +image::tree-shot1.png["shot",title="Vertical Split Container"] + +unfloat::[] + +You probably guessed it already: There is no limit on how deep your hierarchy +of splits can be. + +=== Focus parent + +Let’s stay with our example from above. We have a terminal on the left and two +vertically split terminals on the right, focus is on the bottom right one. When +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+: + +image::tree-shot3.png["shot3",title="Focus parent, then open new terminal"] + +[[configuring]] == Configuring i3 This is where the real fun begins ;-). Most things are very dependant on your @@ -203,6 +254,14 @@ To change the configuration of i3, copy +/etc/i3/config+ to +\~/.i3/config+ (or +~/.config/i3/config+ if you like the XDG directory scheme) and edit it with a text editor. +On first start (and on all following starts, unless you have a configuration +file), i3 will offer you to create a configuration file. You can tell the +wizard to use either Alt (Mod1) or Windows (Mod4) as modifier in the config +file. Also, the created config file will use the key symbols of your current +keyboard layout. To start the wizard, use the command +i3-config-wizard+. +Please note that you must not have +~/.i3/config+, otherwise the wizard will +exit. + === Comments It is possible and recommended to use comments in your configuration file to @@ -216,10 +275,12 @@ a # and can only be used at the beginning of a line: === Fonts -i3 uses X core fonts (not Xft) for rendering window titles and the internal -workspace bar. You can use +xfontsel(1)+ to generate such a font description. -To see special characters (Unicode), you need to use a font which supports -the ISO-10646 encoding. +i3 uses X core fonts (not Xft) for rendering window titles. You can use ++xfontsel(1)+ to generate such a font description. To see special characters +(Unicode), you need to use a font which supports the ISO-10646 encoding. + +If i3 cannot open the configured font, it will output an error in the logfile +and fall back to a working font. *Syntax*: ------------------------------ @@ -244,9 +305,9 @@ also mix your bindings, though i3 will not protect you from overlapping ones). are the ones you use in Xmodmap to remap your keys. To get the current mapping of your keys, use +xmodmap -pke+. -* Keycodes do not need to have a symbol assigned (handy for some hotkeys - on some notebooks) and they will not change their meaning as you switch to a - different keyboard layout (when using +xmodmap+). +* Keycodes do not need to have a symbol assigned (handy for custom vendor + hotkeys on some notebooks) and they will not change their meaning as you + switch to a different keyboard layout (when using +xmodmap+). My recommendation is: If you often switch keyboard layouts but you want to keep your bindings in the same physical location on the keyboard, use keycodes. @@ -256,19 +317,19 @@ keysyms. *Syntax*: ---------------------------------- bindsym [Modifiers+]keysym command -bind [Modifiers+]keycode command +bindcode [Modifiers+]keycode command ---------------------------------- *Examples*: -------------------------------- # Fullscreen -bindsym Mod1+f f +bindsym mod+f f # Restart -bindsym Mod1+Shift+r restart +bindsym mod+Shift+r restart # Notebook-specific hotkeys -bind 214 exec /home/michael/toggle_beamer.sh +bindcode 214 exec /home/michael/toggle_beamer.sh -------------------------------- Available Modifiers: @@ -303,25 +364,49 @@ you hold the shift button as well, the resize will be proportional. floating_modifier -------------------------------- -*Examples*: +*Example*: -------------------------------- floating_modifier Mod1 -------------------------------- +=== Orientation for new workspaces + +New workspaces get a reasonable default orientation: Wide-screen monitors +(anything wider than high) get horizontal orientation, rotated monitors +(anything higher than wide) get vertical orientation. + +With the +default_orientation+ configuration directive, you can override that +behaviour. + +*Syntax*: +---------------------------------------------- +default_orientation +---------------------------------------------- + +*Example*: +---------------------------- +default_orientation vertical +---------------------------- + === Layout mode for new containers -This option determines in which mode new containers will start. See also -<>. +This option determines in which mode new containers on workspace level will +start. +/////////////////////////////// +See also <>. +////////////////////////////// *Syntax*: --------------------------------------------- -new_container -new_container stack-limit +workspace_layout --------------------------------------------- +///////////////////////////////////////////// +new_container stack-limit +///////////////////////////////////////////// -*Examples*: +*Example*: --------------------- -new_container tabbed +workspace_layout tabbed --------------------- === Border style for new windows @@ -330,14 +415,39 @@ This option determines which border style new windows will have. *Syntax*: --------------------------------------------- -new_window +new_window --------------------------------------------- -*Examples*: +*Example*: --------------------- -new_window bp +new_window 1pixel --------------------- +=== Arbitrary commands for specific windows (for_window) + +With the +for_window+ command, you can let i3 execute any command when it +encounters a specific window. This can be used to set windows to floating or to +change their border style, for example. + +*Syntax*: +----------------------------- +for_window [criteria] command +----------------------------- + +*Examples*: +------------------------------------------------ +# enable floating mode for all XTerm windows +for_window [class="XTerm"] mode floating + +# Make all urxvts use a 1-pixel border: +for_window [class="urxvt"] border 1pixel + +# A less useful, but rather funny example: +# makes the window floating as soon as I change +# directory to ~/work +for_window [title="x200: ~/work"] mode floating +------------------------------------------------ + === Variables As you learned in the section about keyboard bindings, you will have @@ -347,10 +457,10 @@ variables can be handy. *Syntax*: -------------- -set name value +set $name value -------------- -*Examples*: +*Example*: ------------------------ set $m Mod1 bindsym $m+Shift+r restart @@ -360,19 +470,20 @@ Variables are directly replaced in the file when parsing. There is no fancy handling and there are 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). ++~/.xsession+ file). === Automatically putting clients on specific workspaces [[assign_workspace]] -It is recommended that you match on window classes wherever 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. +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 +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 @@ -380,36 +491,40 @@ not be put onto any workspace, but will be set floating on the current one. *Syntax*: ------------------------------------------------------------ -assign ["]window class[/window title]["] [→] [~ | workspace] +assign ["]window class[/window title]["] [→] [workspace] ------------------------------------------------------------ *Examples*: ---------------------- assign urxvt 2 assign urxvt → 2 +assign urxvt → work assign "urxvt" → 2 assign "urxvt/VIM" → 3 -assign "gecko" → ~4 -assign "xv/MPlayer" → ~ +assign "gecko" → 4 ---------------------- 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. +use it, it has to be a UTF-8 encoded arrow, not `->` or something like that. === Automatically starting applications on i3 startup -By using the +exec+ keyword outside a keybinding, you can configure which -commands will be performed by i3 on initial startup (not when restarting i3 -in-place however). These commands will be run in order. +By using the +exec+ keyword outside a keybinding, you can configure +which commands will be performed by i3 on initial startup. +exec+ +commands will not run when restarting i3, if you need a command to run +also when restarting i3 you should use the +exec_always+ +keyword. These commands will be run in order. *Syntax*: ------------- +------------------- exec command ------------- +exec_always command +------------------- *Examples*: -------------------------------- -exec sudo i3status | dzen2 -dock +exec i3status | dzen2 -dock +exec_always ~/my_script.sh -------------------------------- [[workspace_screen]] @@ -437,30 +552,9 @@ workspace 1 output LVDS1 workspace 5 output VGA1 --------------------------- -=== Named workspaces - -If you always have a certain arrangement of workspaces, you might want to give -them names (of course UTF-8 is supported): - -*Syntax*: ---------------------------------------- -workspace -workspace output name ---------------------------------------- - -For more details about the 'output' part of this command, see above. - -*Examples*: --------------------------- -workspace 1 www -workspace 2 work -workspace 3 i ♥ workspaces --------------------------- - === Changing colors -You can change all colors which i3 uses to draw the window decorations and the -bottom bar. +You can change all colors which i3 uses to draw the window decorations. *Syntax*: -------------------------------------------- @@ -518,18 +612,22 @@ i3 uses unix sockets to provide an IPC interface. This allows third-party programs to get information from i3, such as the current workspaces (to display a workspace bar), and to control i3. -To enable it, you have to configure a path where the unix socket will be -stored. The default path is +~/.i3/ipc.sock+. +The IPC socket is enabled by default and will be created in ++/tmp/i3-%u/ipc-socket.%p+ where +%u+ is your UNIX username and +%p+ is the PID +of i3. + +You can override the default path through the environment-variable +I3SOCK+ or +by specifying the +ipc-socket+ directive. *Examples*: ---------------------------- -ipc-socket ~/.i3/ipc.sock +ipc-socket /tmp/i3-ipc.sock ---------------------------- You can then use the +i3-msg+ application to perform any command listed in the next section. -=== Disable focus follows mouse +=== Focus follows mouse If you have a setup where your mouse usually is in your way (like a touchpad on your laptop which you do not want to disable completely), you might want @@ -542,119 +640,146 @@ to click on links in your browser window). focus_follows_mouse ---------------------------- -*Examples*: +*Example*: ---------------------- focus_follows_mouse no ---------------------- -=== Internal workspace bar +=== Popups during fullscreen mode -The internal workspace bar (the thing at the bottom of your screen) is very -simple -- it does not provide a way to display custom text and it does not -offer advanced customization features. This is intended because we do not -want to duplicate functionality of tools like +dzen2+, +xmobar+ and so on -(they render bars, we manage windows). Instead, there is an option which will -turn off the internal bar completely, so that you can use a separate program to -display it (see +i3-wsbar+, a sample implementation of such a program): +When you are in fullscreen mode, some applications still open popup windows +(take Xpdf for example). This is because these applications may not be aware +that they are in fullscreen mode (they do not check the corresponding hint). +There are two things which are possible to do in this situation: + +1. Just ignore the popup (don’t map it). This won’t interrupt you while you are + in fullscreen. However, some apps might react badly to this (deadlock until + you go out of fullscreen). +2. Leave fullscreen mode. This is the default. *Syntax*: ----------------------- -workspace_bar ----------------------- +------------------------------------------------- +popup_during_fullscreen +------------------------------------------------- -*Examples*: ----------------- -workspace_bar no ----------------- +*Example*: +------------------------------ +popup_during_fullscreen ignore +------------------------------ == List of commands +=== Splitting containers + +The split command makes the current window a split container. Split containers +can contain multiple windows. Every split container has an orientation, it is +either split horizontally (a new window gets placed to the right of the current +one) or vertically (a new window gets placed below the current one). + +If you apply this command to a split container with the same orientation, +nothing will happen. If you use a different orientation, the split container’s +orientation will be changed (if it does not have more than one window). + +*Syntax*: +--------------------------- +split +--------------------------- + +*Example*: +-------------- +split vertical +-------------- + === Manipulating layout -To change the layout of the current container to stacking, use +s+, for default -use +d+ and for tabbed, use +T+. To make the current client (!) fullscreen, -use +f+, to make it span all outputs, use +fg+, to make it floating (or -tiling again) use +t+: +Use +layout default+, +layout stacking+ or +layout tabbed+ to change the +current container layout to default, stacking or tabbed layout, respectively. + +To make the current window (!) fullscreen, use +fullscreen+, to make +it floating (or tiling again) use +floating enable+ respectively +floating disable+ +(or +floating toggle+): *Examples*: -------------- -bindsym Mod1+s s -bindsym Mod1+l d -bindsym Mod1+w T +bindsym mod+s layout stacking +bindsym mod+l layout default +bindsym mod+w layout tabbed # Toggle fullscreen -bindsym Mod1+f f - -# Toggle global fullscreen -bindsym Mod1+Shift+f fg +bindsym mod+f fullscreen # Toggle floating/tiling -bindsym Mod1+t t +bindsym mod+t floating toggle -------------- -=== Focusing/Moving/Snapping clients/containers/screens +=== Focusing/Moving containers + +To change the focus, use the focus command: +focus left+, +focus right+, +focus down+ and +focus up+. + +There are a few special parameters you can use for the focus command: -To change the focus, use one of the +h+, +j+, +k+ and +l+ commands, meaning -left, down, up, right (respectively). To focus a container, prefix it with -+wc+. To focus a screen, prefix it with +ws+. +parent:: + Sets focus to the +Parent Container+ of the current +Container+. +child:: + The opposite of +focus parent+, sets the focus to the last focused + child container. +floating:: + Sets focus to the last focused floating container. +tiling:: + Sets focus to the last focused tiling container. +mode_toggle:: + Toggles between floating/tiling containers. -The same principle applies for moving and snapping: just prefix the command -with +m+ when moving and with +s+ when snapping: +For moving, use +move left+, +move right+, +move down+ and +move up+. *Examples*: ---------------------- # Focus clients on the left, bottom, top, right: -bindsym Mod1+j h -bindsym Mod1+k j -bindsym Mod1+j k -bindsym Mod1+semicolon l +bindsym mod+j focus left +bindsym mod+k focus down +bindsym mod+l focus up +bindsym mod+semicolon focus right + +# Focus parent container +bindsym mod+u focus parent + +# Focus last floating/tiling container +bindsym mod+g focus mode_toggle # Move client to the left, bottom, top, right: -bindsym Mod1+j mh -bindsym Mod1+k mj -bindsym Mod1+j mk -bindsym Mod1+semicolon ml - -# Snap client to the left, bottom, top, right: -bindsym Mod1+j sh -bindsym Mod1+k sj -bindsym Mod1+j sk -bindsym Mod1+semicolon sl - -# Focus container on the left, bottom, top, right: -bindsym Mod3+j wch -… +bindsym mod+j move left +bindsym mod+k move down +bindsym mod+l move up +bindsym mod+semicolon move right ---------------------- -=== Changing workspaces/moving clients to workspaces +=== Changing workspaces/moving containers to workspaces -To change to a specific workspace, the command is just the number of the -workspace, e.g. +1+ or +3+. To move the current client to a specific workspace, -prefix the number with an +m+. +To change to a specific workspace, use the +workspace+ command, followed by the +number or name of the workspace. To move containers to specific workspaces, use ++move workspace+. -You can also switch to the next and previous workspace with the commands +nw+ -and +pw+, which is handy, for example, if you have workspace 1, 3, 4 and 9 and -you want to cycle through them with a single key combination. +You can also switch to the next and previous workspace with the commands ++workspace next+ and +workspace prev+, which is handy, for example, if you have +workspace 1, 3, 4 and 9 and you want to cycle through them with a single key +combination. *Examples*: ------------------------- -bindsym Mod1+1 1 -bindsym Mod1+2 2 +bindsym mod+1 workspace 1 +bindsym mod+2 workspace 2 ... -bindsym Mod1+Shift+1 m1 -bindsym Mod1+Shift+2 m2 +bindsym mod+Shift+1 move workspace 1 +bindsym mod+Shift+2 move workspace 2 ... - -bindsym Mod1+o nw -bindsym Mod1+p pw ------------------------- [[resizingconfig]] -=== Resizing columns/rows +=== Resizing containers/windows -If you want to resize columns/rows using your keyboard, you can use the +If you want to resize containers/windows using your keyboard, you can use the +resize+ command, I recommend using it inside a so called +mode+: .Example: Configuration file, defining a mode for resizing @@ -666,23 +791,23 @@ mode "resize" { # when pressing left, the window is resized so that it has # more space on its left - bindsym n resize left -10 - bindsym Shift+n resize left +10 + bindsym j resize shrink left + bindsym Shift+j resize grow left - bindsym r resize bottom +10 - bindsym Shift+r resize bottom -10 + bindsym k resize grow bottom + bindsym Shift+k resize shrink bottom - bindsym t resize top -10 - bindsym Shift+t resize top +10 + bindsym l resize shrink top + bindsym Shift+l resize grow top - bindsym d resize right +10 - bindsym Shift+d resize right -10 + bindsym semicolon resize grow right + bindsym Shift+semicolon resize shrink right - bind 36 mode default + bindcode 36 mode default } # Enter resize mode -bindsym Mod1+r mode resize +bindsym mod+r mode "resize" ---------------------------------------------------------------------- === Jumping to specific windows @@ -691,23 +816,20 @@ Often when in a multi-monitor environment, you want to quickly jump to a specific window. For example, while working on workspace 3 you may want to jump to your mail client to email your boss that you’ve achieved some important goal. Instead of figuring out how to navigate to your mailclient, -it would be more convenient to have a shortcut. +it would be more convenient to have a shortcut. You can use the +focus+ command +with criteria for that. *Syntax*: ---------------------------------------------------- -jump ["]window class[/window title]["] -jump workspace [ column row ] +[class="class"] focus +[title="title"] focus ---------------------------------------------------- -You can either use the same matching algorithm as in the +assign+ command -(see above) or you can specify the position of the client if you always use -the same layout. - *Examples*: --------------------------------------- +------------------------------------------------ # Get me to the next open VIM instance -bindsym Mod1+a jump "urxvt/VIM" --------------------------------------- +bindsym mod+a [class="urxvt" title="VIM"] focus +------------------------------------------------ === VIM-like marks (mark/goto) @@ -726,68 +848,57 @@ for this purpose: It lets you input a command and sends the command to i3. It can also prefix this command and display a custom prompt for the input dialog. *Syntax*: ------------------ -mark -goto ------------------ +------------------------------ +mark identifier +[con_mark="identifier"] focus +------------------------------ +*Example (in a terminal)*: +------------------------------ +$ i3-msg mark irssi +$ i3-msg '[con_mark="irssi"] focus' +------------------------------ + +/////////////////////////////////////////////////////////////////// +TODO: make i3-input replace %s *Examples*: --------------------------------------- # Read 1 character and mark the current window with this character -bindsym Mod1+m exec i3-input -p 'mark ' -l 1 -P 'Mark: ' +bindsym mod+m exec i3-input -p 'mark ' -l 1 -P 'Mark: ' # Read 1 character and go to the window with the character -bindsym Mod1+g exec i3-input -p 'goto ' -l 1 -P 'Goto: ' +bindsym mod+g exec i3-input -p 'goto ' -l 1 -P 'Goto: ' --------------------------------------- Alternatively, if you do not want to mess with +i3-input+, you could create seperate bindings for a specific set of labels and then only use those labels. - -=== Traveling the focus stack - -This mechanism can be thought of as the opposite of the +jump+ command. -It travels the focus stack and jumps to the window which had focus previously. - -*Syntax*: --------------- -focus [number] | floating | tiling | ft --------------- - -Where +number+ by default is 1 meaning that the next client in the focus stack -will be selected. - -The special values have the following meaning: - -floating:: - The next floating window is selected. -tiling:: - The next tiling window is selected. -ft:: - If the current window is floating, the next tiling window will be - selected; and vice-versa. +/////////////////////////////////////////////////////////////////// === Changing border style -To change the border of the current client, you can use +bn+ to use the normal -border (including window title), +bp+ to use a 1-pixel border (no window title) -and +bb+ to make the client borderless. There is also +bt+ which will toggle -the different border styles. +To change the border of the current client, you can use +border normal+ to use the normal +border (including window title), +border 1pixel+ 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. *Examples*: ------------------- -bindsym Mod1+t bn -bindsym Mod1+y bp -bindsym Mod1+u bb ------------------- +---------------------------- +bindsym mod+t border normal +bindsym mod+y border 1pixel +bindsym mod+u border none +---------------------------- [[stack-limit]] +/////////////////////////////////////////////////////////////////////////////// +TODO: not yet implemented === Changing the stack-limit of a container If you have a single container with a lot of windows inside it (say, more than 10), the default layout of a stacking container can get a little unhandy. -Depending on your screen’s size, you might end up seeing only half of the -titlebars for each window in the container. +Depending on your screen’s size, you might end up with only half of the title +lines being actually used, wasting a lot of screen space. Using the +stack-limit+ command, you can limit the number of rows or columns in a stacking container. i3 will create columns or rows (depending on what @@ -808,22 +919,21 @@ stack-limit rows 5 ------------------- image:stacklimit.png[Container limited to two columns] +/////////////////////////////////////////////////////////////////////////////// === Reloading/Restarting/Exiting You can make i3 reload its configuration file with +reload+. You can also restart i3 inplace with the +restart+ command to get it out of some weird state (if that should ever happen) or to perform an upgrade without having to restart -your X session. However, your layout is not preserved at the moment, meaning -that all open windows will end up in a single container in default layout -after the restart. To exit i3 properly, you can use the +exit+ command, +your X session. To exit i3 properly, you can use the +exit+ command, however you don’t need to (simply killing your X session is fine as well). *Examples*: ---------------------------- -bindsym Mod1+Shift+r restart -bindsym Mod1+Shift+w reload -bindsym Mod1+Shift+e exit +bindsym mod+Shift+r restart +bindsym mod+Shift+w reload +bindsym mod+Shift+e exit ---------------------------- [[multi_monitor]] @@ -945,24 +1055,16 @@ approach you have in the task bar of a traditional desktop environment. If you don’t already have your favorite way of generating such a status line (self-written scripts, conky, …), then i3status is the recommended tool for this task. It was written in C with the goal of using as few syscalls as -possible to reduce the time your CPU is woken up from sleep states. - -Regardless of which application you use to generate the status line, you -want to make sure that the application does one of the following things: - -1. Register as a dock window using EWMH hints. This will make i3 position the - window above the workspace bar but below every other client. This is the - recommended way, but in case of dzen2, for example, you need to check out - the source of dzen2 from subversion, as the -dock option is not present - in the released versions. -2. Overlay the internal workspace bar. This method will not waste any space - on the workspace bar, however, it is rather hackish. Just configure - the output window to be over the workspace bar (say -x 200 and -y 780 if - your screen is 800 px height). - -The planned solution for this problem is to make the workspace bar optional -and switch to a third party application completely (dzen2 for example) -which will then contain the workspace bar. +possible to reduce the time your CPU is woken up from sleep states. Because +i3status only spits out text, you need to combine it with some other tool, like +i3bar. Use a pipe to connect them: +i3status | i3bar -d+. + +Regardless of which application you use to display the status line, you +want to make sure that it registers as a dock window using EWMH hints. i3 will +position the window either at the top or at the bottom of the screen, depending +on which hint the application sets. With i3bar, you can use +-d+ or +-dbottom+ +for positioning it at the bottom and +-dtop+ to position it at the top of the +screen. === Giving presentations (multi-monitor) diff --git a/css/style.css b/css/style.css index 30d413d..95ff56a 100644 --- a/css/style.css +++ b/css/style.css @@ -343,6 +343,27 @@ img { padding-left: 1em; } +.docs strong { + margin-right: 1em; +} + +.docversion { + margin: 0.25em; + margin-top: 0.9em; + padding: 0.1em; + padding-left: 0.25em; + padding-right: 0.25em; + background-color: #333; + border: 2px solid #555; + border-radius: 4px; + float: right; +} + +.docversion a, .docversion a:visited { + color: white; + text-decoration: none; +} + /* clearfix */ .clearfix:after { content: "."; diff --git a/docs/3.e/bigpicture.png b/docs/3.e/bigpicture.png new file mode 100644 index 0000000..fc3c8db Binary files /dev/null and b/docs/3.e/bigpicture.png differ diff --git a/docs/3.e/debugging.html b/docs/3.e/debugging.html new file mode 100644 index 0000000..9ff561e --- /dev/null +++ b/docs/3.e/debugging.html @@ -0,0 +1,147 @@ + + + + + + +i3: Debugging i3: How To + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes how to debug i3 suitably for sending us useful bug +reports, even if you have no clue of C programming.

+

First of all: Thank you for being interested in debugging i3. It really means +something to us to get your bug fixed. If you have any questions about the +debugging and/or need further help, do not hesitate to contact us!

+
+
+
+

1. Enabling logging

+
+

i3 spits out much information onto stdout, if told so. To have a clearly +defined place where log files will be saved, you should redirect stdout and +stderr in xsession. While you’re at it, putting each run of i3 in a separate +log file with date/time in it is a good idea to not get confused about the +different log files later on.

+
+
+
exec /usr/bin/i3 -V -d all >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
+
+
+
+
+

2. Enabling core dumps

+
+

When i3 crashes, often you have the chance of getting a core dump (an image +of the memory of the i3 process which can be loaded into a debugger). To get a +core dump, you have to make sure that the user limit for core dump files is set +high enough. Many systems ship with a default value which even forbids core +dumps completely. To disable the limit completely and thus enable core dumps, +use the following command (in your .xsession, before starting i3):

+
+
+
ulimit -c unlimited
+
+

Furthermore, to easily recognize core dumps and allow multiple of them, you +should set a custom core dump filename pattern, using a command like the +following:

+
+
+
sudo sysctl -w kernel.core_pattern=core.%e.%p
+
+

This will generate files which have the executable’s file name (%e) and the +process id (%p) in it. You can save this setting across reboots using +/etc/sysctl.conf.

+
+
+
+

3. Compiling with debug symbols

+
+

To actually get useful core dumps, you should make sure that your version of i3 +is compiled with debug symbols, that is, that they are not stripped during the +build process. You can check whether your executable contains symbols by +issuing the following command:

+
+
+
file $(which i3)
+
+

You should get an output like this:

+
+
+
/usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
+linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
+
+

Notice the not stripped, which is the important part. If you have a version +which is stripped, please have a look if your distribution provides debug +symbols (package i3-wm-dbg on Debian for example) or if you can turn off +stripping. If nothing helps, please build i3 from source.

+
+
+
+

4. Generating a backtrace

+
+

Once you have made sure that your i3 is compiled with debug symbols and that +core dumps are enabled, you can start making sense out of the core dumps.

+

Because the core dump depends on the original executable (and its debug +symbols), please do this as soon as you encounter the problem. If you +re-compile i3, your core dump might be useless afterwards.

+

Please install gdb, a debugger for C. No worries, you don’t need to learn it +now. Start gdb using the following command (replacing the actual name of the +core dump of course):

+
+
+
gdb $(which i3) core.i3.3849
+
+

Then, generate a backtrace using:

+
+
+
backtrace full
+
+
+
+
+

5. Sending bug reports/debugging on IRC

+
+

When sending bug reports, please paste the relevant part of the log (if in +doubt, please send us rather too much information than too less) and the whole +backtrace (if there was a core dump).

+

When debugging with us in IRC, be prepared to use a so called nopaste service +such as http://nopaste.info or http://pastebin.com because pasting large +amounts of text in IRC sometimes leads to incomplete lines (servers have line +length limitations) or flood kicks.

+
+
+
+
+ + + diff --git a/docs/3.e/hacking-howto.html b/docs/3.e/hacking-howto.html new file mode 100644 index 0000000..90029de --- /dev/null +++ b/docs/3.e/hacking-howto.html @@ -0,0 +1,890 @@ + + + + + + +i3: Hacking i3: How To + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document is intended to be the first thing you read before looking and/or +touching i3’s source code. It should contain all important information to help +you understand why things are like they are. If it does not mention something +you find necessary, please do not hesitate to contact me.

+
+
+
+

1. Window Managers

+
+

A window manager is not necessarily needed to run X, but it is usually used in +combination with X to facilitate some things. The window manager’s job is to +take care of the placement of windows, to provide the user with some mechanisms +to change the position/size of windows and to communicate with clients to a +certain extent (for example handle fullscreen requests of clients such as +MPlayer).

+

There are no different contexts in which X11 clients run, so a window manager +is just another client, like all other X11 applications. However, it handles +some events which normal clients usually don’t handle.

+

In the case of i3, the tasks (and order of them) are the following:

+
    +
  1. +

    +Grab the key bindings (events will be sent upon keypress/keyrelease) +

    +
    2. +
  2. +

    +Iterate through all existing windows (if the window manager is not started as + the first client of X) and manage them (reparent them, create window + decorations, etc.) +

    +
    3. +
  3. +

    +When new windows are created, manage them +

    +
    4. +
  4. +

    +Handle the client’s _WM_STATE property, but only the _WM_STATE_FULLSCREEN +

    +
    5. +
  5. +

    +Handle the client’s WM_NAME property +

    +
    6. +
  6. +

    +Handle the client’s size hints to display them proportionally +

    +
    7. +
  7. +

    +Handle the client’s urgency hint +

    +
    8. +
  8. +

    +Handle enter notifications (focus follows mouse) +

    +
    9. +
  9. +

    +Handle button (as in mouse buttons) presses for focus/raise on click +

    +
    10. +
  10. +

    +Handle expose events to re-draw own windows such as decorations +

    +
    11. +
  11. +

    +React to the user’s commands: Change focus, Move windows, Switch workspaces, + Change the layout mode of a container (default/stacking/tabbed), start a new + application, restart the window manager +

    +
    12. +
+

In the following chapters, each of these tasks and their implementation details +will be discussed.

+
+

1.1. Tiling window managers

+

Traditionally, there are two approaches to managing windows: The most common +one nowadays is floating, which means the user can freely move/resize the +windows. The other approach is called tiling, which means that your window +manager distributes windows to use as much space as possible while not +overlapping each other.

+

The idea behind tiling is that you should not need to waste your time +moving/resizing windows while you usually want to get some work done. After +all, most users sooner or later tend to lay out their windows in a way which +corresponds to tiling or stacking mode in i3. Therefore, why not let i3 do this +for you? Certainly, it’s faster than you could ever do it.

+

The problem with most tiling window managers is that they are too unflexible. +In my opinion, a window manager is just another tool, and similar to vim which +can edit all kinds of text files (like source code, HTML, …) and is not limited +to a specific file type, a window manager should not limit itself to a certain +layout (like dwm, awesome, …) but provide mechanisms for you to easily create +the layout you need at the moment.

+
+
+

1.2. The layout table

+

To accomplish flexible layouts, we decided to simply use a table. The table +grows and shrinks as you need it. Each cell holds a container which then holds +windows (see picture below). You can use different layouts for each container +(default layout and stacking layout).

+

So, when you open a terminal and immediately open another one, they reside in +the same container, in default layout. The layout table has exactly one column, +one row and therefore one cell. When you move one of the terminals to the +right, the table needs to grow. It will be expanded to two columns and one row. +This enables you to have different layouts for each container. The table then +looks like this:

+
+ +++ + + + + + +

T1

T2

+
+

When moving terminal 2 to the bottom, the table will be expanded again.

+
+ +++ + + + + + + + + + +

T1

T2

+
+

You can really think of the layout table like a traditional HTML table, if +you’ve ever designed one. Especially col- and rowspan work similarly. Below, +you see an example of colspan=2 for the first container (which has T1 as +window).

+
+ ++ + + + + + + + +
+
+
T1
+
+ +++ + + + + + +

T2

T3

+
+
+

Furthermore, you can freely resize table cells.

+
+
+
+
+

2. Files

+
+
+
+include/data.h +
+
+

+Contains data definitions used by nearly all files. You really need to read +this first. +

+
+
+include/*.h +
+
+

+Contains forward definitions for all public functions, as well as +doxygen-compatible comments (so if you want to get a bit more of the big +picture, either browse all header files or use doxygen if you prefer that). +

+
+
+src/cfgparse.l +
+
+

+Contains the lexer for i3’s configuration file, written for flex(1). +

+
+
+src/cfgparse.y +
+
+

+Contains the parser for i3’s configuration file, written for bison(1). +

+
+
+src/click.c +
+
+

+Contains all functions which handle mouse button clicks (right mouse button +clicks initiate resizing and thus are relatively complex). +

+
+
+src/client.c +
+
+

+Contains all functions which are specific to a certain client (make it +fullscreen, see if its class/name matches a pattern, kill it, …). +

+
+
+src/commands.c +
+
+

+Parsing commands and actually executing them (focusing, moving, …). +

+
+
+src/config.c +
+
+

+Parses the configuration file. +

+
+
+src/debug.c +
+
+

+Contains debugging functions to print unhandled X events. +

+
+
+src/floating.c +
+
+

+Contains functions for floating mode (mostly resizing/dragging). +

+
+
+src/handlers.c +
+
+

+Contains all handlers for all kinds of X events (new window title, new hints, +unmapping, key presses, button presses, …). +

+
+
+src/ipc.c +
+
+

+Contains code for the IPC interface. +

+
+
+src/layout.c +
+
+

+Renders your layout (screens, workspaces, containers). +

+
+
+src/mainx.c +
+
+

+Initializes the window manager. +

+
+
+src/manage.c +
+
+

+Looks at existing or new windows and decides whether to manage them. If so, it +reparents the window and inserts it into our data structures. +

+
+
+src/resize.c +
+
+

+Contains the functions to resize columns/rows in the table. +

+
+
+src/table.c +
+
+

+Manages the most important internal data structure, the design table. +

+
+
+src/util.c +
+
+

+Contains useful functions which are not really dependant on anything. +

+
+
+src/workspace.c +
+
+

+Contains all functions related to workspaces (displaying, hiding, renaming…) +

+
+
+src/xcb.c +
+
+

+Contains wrappers to use xcb more easily. +

+
+
+src/xinerama.c +
+
+

+(Re-)initializes the available screens and converts them to virtual screens +(see below). +

+
+
+
+
+
+

3. Data structures

+
+

See include/data.h for documented data structures. The most important ones are +explained right here.

+

+The Big Picture +

+

So, the hierarchy is:

+
    +
  1. +

    +Virtual screens (Screen 0 in this example) +

    +
    2. +
  2. +

    +Workspaces (Workspace 1 in this example) +

    +
    3. +
  3. +

    +Table (There can only be one table per Workspace) +

    +
    4. +
  4. +

    +Container (left and right in this example) +

    +
    5. +
  5. +

    +Client (The two clients in the left container) +

    +
    6. +
+
+

3.1. Virtual screens

+

A virtual screen (type i3Screen) is generated from the connected screens +obtained through Xinerama. The difference to the raw Xinerama monitors as seen +when using xrandr(1) is that it falls back to the lowest common resolution of +the logical screens.

+

For example, if your notebook has 1280x800 and you connect a video projector +with 1024x768, set up in clone mode (xrandr --output VGA --mode 1024x768 +--same-as LVDS), i3 will have one virtual screen.

+

However, if you configure it using xrandr --output VGA --mode 1024x768 +--right-of LVDS, i3 will generate two virtual screens. For each virtual +screen, a new workspace will be assigned. New workspaces are created on the +screen you are currently on.

+
+
+

3.2. Workspace

+

A workspace is identified by its number. Basically, you could think of +workspaces as different desks in your office, if you like the desktop +methaphor. They just contain different sets of windows and are completely +separate of each other. Other window managers also call this “Virtual +desktops”.

+
+
+

3.3. The layout table

+

Each workspace has a table, which is just a two-dimensional dynamic array +containing Containers (see below). This table grows and shrinks as you need it +(by moving windows to the right you can create a new column in the table, by +moving them to the bottom you create a new row).

+
+
+

3.4. Container

+

A container is the content of a table’s cell. It holds an arbitrary amount of +windows and has a specific layout (default layout, stack layout or tabbed +layout). Containers can consume multiple table cells by modifying their +colspan/rowspan attribute.

+
+
+

3.5. Client

+

A client is x11-speak for a window.

+
+
+
+
+

4. List/queue macros

+
+

i3 makes heavy use of the list macros defined in BSD operating systems. To +ensure that the operating system on which i3 is compiled has all the expected +features, i3 comes with include/queue.h. On BSD systems, you can use man +queue(3). On Linux, you have to use google (or read the source).

+

The lists used are SLIST (single linked lists), CIRCLEQ (circular +queues) and TAILQ (tail queues). Usually, only forward traversal is necessary, +so an SLIST works fine. If inserting elements at arbitrary positions or at +the end of a list is necessary, a TAILQ is used instead. However, for the +windows inside a container, a CIRCLEQ is necessary to go from the currently +selected window to the window above/below.

+
+
+
+

5. Naming conventions

+
+

There is a row of standard variables used in many events. The following names +should be chosen for those:

+
    +
  • +

    +“conn” is the xcb_connection_t +

    +
    • +
  • +

    +“event” is the event of the particular type +

    +
    • +
  • +

    +“container” names a container +

    +
    • +
  • +

    +“client” names a client, for example when using a CIRCLEQ_FOREACH +

    +
    • +
+
+
+
+

6. Startup (src/mainx.c, main())

+
+
    +
  • +

    +Establish the xcb connection +

    +
    • +
  • +

    +Check for XKB extension on the separate X connection +

    +
    • +
  • +

    +Check for Xinerama screens +

    +
    • +
  • +

    +Grab the keycodes for which bindings exist +

    +
    • +
  • +

    +Manage all existing windows +

    +
    • +
  • +

    +Enter the event loop +

    +
    • +
+
+
+
+

7. Keybindings

+
+
+

7.1. Grabbing the bindings

+

Grabbing the bindings is quite straight-forward. You pass X your combination of +modifiers and the keycode you want to grab and whether you want to grab them +actively or passively. Most bindings (everything except for bindings using +Mode_switch) are grabbed passively, that is, just the window manager gets the +event and cannot replay it.

+

We need to grab bindings that use Mode_switch actively because of a bug in X. +When the window manager receives the keypress/keyrelease event for an actively +grabbed keycode, it has to decide what to do with this event: It can either +replay it so that other applications get it or it can prevent other +applications from receiving it.

+

So, why do we need to grab keycodes actively? Because X does not set the +state-property of keypress/keyrelease events properly. The Mode_switch bit is +not set and we need to get it using XkbGetState. This means we cannot pass X +our combination of modifiers containing Mode_switch when grabbing the key and +therefore need to grab the keycode itself without any modifiers. This means, +if you bind Mode_switch + keycode 38 ("a"), i3 will grab keycode 38 ("a") and +check on each press of "a" if the Mode_switch bit is set using XKB. If yes, it +will handle the event, if not, it will replay the event.

+
+
+

7.2. Handling a keypress

+

As mentioned in "Grabbing the bindings", upon a keypress event, i3 first gets +the correct state.

+

Then, it looks through all bindings and gets the one which matches the received +event.

+

The bound command is parsed directly in command mode.

+
+
+
+
+

8. Manage windows (src/mainx.c, manage_window() and reparent_window())

+
+

manage_window() does some checks to decide whether the window should be +managed at all:

+
    +
  • +

    +Windows have to be mapped, that is, visible on screen +

    +
    • +
  • +

    +The override_redirect must not be set. Windows with override_redirect shall + not be managed by a window manager +

    +
    • +
+

Afterwards, i3 gets the intial geometry and reparents the window (see +reparent_window()) if it wasn’t already managed.

+

Reparenting means that for each window which is reparented, a new window, +slightly larger than the original one, is created. The original window is then +reparented to the bigger one (called "frame").

+

After reparenting, the window type (_NET_WM_WINDOW_TYPE) is checked to see +whether this window is a dock (_NET_WM_WINDOW_TYPE_DOCK), like dzen2 for +example. Docks are handled differently, they don’t have decorations and are not +assigned to a specific container. Instead, they are positioned at the bottom +of the screen. To get the height which needsd to be reserved for the window, +the _NET_WM_STRUT_PARTIAL property is used.

+

Furthermore, the list of assignments (to other workspaces, which may be on +other screens) is checked. If the window matches one of the user’s criteria, +it may either be put in floating mode or moved to a different workspace. If the +target workspace is not visible, the window will not be mapped.

+
+
+
+

9. What happens when an application is started?

+
+

i3 does not care for applications. All it notices is when new windows are +mapped (see src/handlers.c, handle_map_request()). The window is then +reparented (see section "Manage windows").

+

After reparenting the window, render_layout() is called which renders the +internal layout table. The new window has been placed in the currently focused +container and therefore the new window and the old windows (if any) need to be +moved/resized so that the currently active layout (default/stacking/tabbed mode) +is rendered correctly. To move/resize windows, a window is “configured” in +X11-speak.

+

Some applications, such as MPlayer obviously assume the window manager is +stupid and try to configure their windows by themselves. This generates an +event called configurerequest. i3 handles these events and tells the window the +size it had before the configurerequest (with the exception of not yet mapped +windows, which get configured like they want to, and floating windows, which +can reconfigure themselves).

+
+
+
+

10. _NET_WM_STATE

+
+

Only the _NET_WM_STATE_FULLSCREEN atom is handled. It calls +“toggle_fullscreen()” for the specific client which just configures the +client to use the whole screen on which it currently is. Also, it is set as +fullscreen_client for the i3Screen.

+
+
+
+

11. WM_NAME

+
+

When the WM_NAME property of a window changes, its decoration (containing the +title) is re-rendered. Note that WM_NAME is in COMPOUND_TEXT encoding which is +totally uncommon and cumbersome. Therefore, the _NET_WM_NAME atom will be used +if present.

+
+
+
+

12. _NET_WM_NAME

+
+

Like WM_NAME, this atom contains the title of a window. However, _NET_WM_NAME +is encoded in UTF-8. i3 will recode it to UCS-2 in order to be able to pass it +to X. Using an appropriate font (ISO-10646), you can see most special +characters (every special character contained in your font).

+
+
+
+

13. Size hints

+
+

Size hints specify the minimum/maximum size for a given window as well as its +aspect ratio. This is important for clients like mplayer, who only set the +aspect ratio and resize their window to be as small as possible (but only with +some video outputs, for example in Xv, while when using x11, mplayer does the +necessary centering for itself).

+

So, when an aspect ratio was specified, i3 adjusts the height of the window +until the size maintains the correct aspect ratio. For the code to do this, see +src/layout.c, function resize_client().

+
+
+
+

14. Rendering (src/layout.c, render_layout() and render_container())

+
+

There are several entry points to rendering: render_layout(), +render_workspace() and render_container(). The former one calls +render_workspace() for every screen, which in turn will call +render_container() for every container inside its layout table. Therefore, if +you need to render only a single container, for example because a window was +removed, added or changed its title, you should directly call +render_container().

+

Rendering consists of two steps: In the first one, in render_workspace(), each +container gets its position (screen offset + offset in the table) and size +(container’s width times colspan/rowspan). Then, render_container() is called, +which takes different approaches, depending on the mode the container is in:

+
+

14.1. Common parts

+

On the frame (the window which was created around the client’s window for the +decorations), a black rectangle is drawn as a background for windows like +MPlayer, which do not completely fit into the frame.

+
+
+

14.2. Default mode

+

Each clients gets the container’s width and an equal amount of height.

+
+
+

14.3. Stack mode

+

In stack mode, a window containing the decorations of all windows inside the +container is placed at the top. The currently focused window is then given the +whole remaining space.

+
+
+

14.4. Tabbed mode

+

Tabbed mode is like stack mode, except that the window decorations are drawn +in one single line at the top of the container.

+
+
+

14.5. Window decorations

+

The window decorations consist of a rectangle in the appropriate color (depends +on whether this window is the currently focused one, the last focused one in a +not focused container or not focused at all) forming the background. +Afterwards, two lighter lines are drawn and the last step is drawing the +window’s title (see WM_NAME) onto it.

+
+
+

14.6. Fullscreen windows

+

For fullscreen windows, the rect (x, y, width, height) is not changed to +allow the client to easily go back to its previous position. Instead, +fullscreen windows are skipped when rendering.

+
+
+

14.7. Resizing containers

+

By clicking and dragging the border of a container, you can resize the whole +column (respectively row) which this container is in. This is necessary to keep +the table layout working and consistent.

+

The resizing works similarly to the resizing of floating windows or movement of +floating windows:

+
    +
  • +

    +A new, invisible window with the size of the root window is created + (grabwin) +

    +
    • +
  • +

    +Another window, 2px width and as high as your screen (or vice versa for + horizontal resizing) is created. Its background color is the border color and + it is only there to inform the user how big the container will be (it + creates the impression of dragging the border out of the container). +

    +
    • +
  • +

    +The drag_pointer function of src/floating.c is called to grab the pointer + and enter its own event loop which will pass all events (expose events) but + motion notify events. This function then calls the specified callback + (resize_callback) which does some boundary checking and moves the helper + window. As soon as the mouse button is released, this loop will be + terminated. +

    +
    • +
  • +

    +The new width_factor for each involved column (respectively row) will be + calculated. +

    +
    • +
+
+
+
+
+

15. User commands / commandmode (src/commands.c)

+
+

Like in vim, you can control i3 using commands. They are intended to be a +powerful alternative to lots of shortcuts, because they can be combined. There +are a few special commands, which are the following:

+
+
+exec <command> +
+
+

+Starts the given command by passing it to /bin/sh. +

+
+
+restart +
+
+

+Restarts i3 by executing argv[0] (the path with which you started i3) without +forking. +

+
+
+w +
+
+

+"With". This is used to select a bunch of windows. Currently, only selecting +the whole container in which the window is in, is supported by specifying "w". +

+
+
+f, s, d +
+
+

+Toggle fullscreen, stacking, default mode for the current window/container. +

+
+
+

The other commands are to be combined with a direction. The directions are h, +j, k and l, like in vim (h = left, j = down, k = up, l = right). When you just +specify the direction keys, i3 will move the focus in that direction. You can +provide "m" or "s" before the direction to move a window respectively or snap.

+
+
+
+

16. Gotchas

+
+
    +
  • +

    +Forgetting to call xcb_flush(conn); after sending a request. This usually + leads to code which looks like it works fine but which does not work under + certain conditions. +

    +
    • +
+
+
+
+

17. Using git / sending patches

+
+

For a short introduction into using git, see +http://www.spheredev.org/wiki/Git_for_the_lazy or, for more documentation, see +http://git-scm.com/documentation

+

When you want to send a patch because you fixed a bug or implemented a cool +feature (please talk to us before working on features to see whether they are +maybe already implemented, not possible for some some reason, or don’t fit +into the concept), please use git to create a patchfile.

+

First of all, update your working copy to the latest version of the master +branch:

+
+
+
git pull
+
+

Afterwards, make the necessary changes for your bugfix/feature. Then, review +the changes using git diff (you might want to enable colors in the diff using +git config diff.color auto). When you are definitely done, use git commit +-a to commit all changes you’ve made.

+

Then, use the following command to generate a patchfile which we can directly +apply to the branch, preserving your commit message and name:

+
+
+
git format-patch origin
+
+

Just send us the generated file via email.

+
+
+
+
+ + + diff --git a/docs/3.e/i3.html b/docs/3.e/i3.html new file mode 100644 index 0000000..4a3a4e6 --- /dev/null +++ b/docs/3.e/i3.html @@ -0,0 +1,529 @@ + + + + + + +i3: i3(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3 - an improved dynamic, tiling window manager

+
+
+
+

2. SYNOPSIS

+
+

i3 [-a] [-c configfile] [-C] [-d <loglevel>] [-v] [-V]

+
+
+
+

3. OPTIONS

+
+
+
+-a +
+
+

+Disables autostart. +

+
+
+-c +
+
+

+Specifies an alternate configuration file path. +

+
+
+-C +
+
+

+Check the configuration file for validity and exit. +

+
+
+-d +
+
+

+Specifies the debug loglevel. To see the most output, use -d all. +

+
+
+-v +
+
+

+Display version number (and date of the last commit). +

+
+
+-V +
+
+

+Be verbose. +

+
+
+
+
+
+

4. DESCRIPTION

+
+
+

4.1. INTRODUCTION

+

i3 was created because wmii, our favorite window manager at the time, didn’t +provide some features we wanted (multi-monitor done right, for example), had +some bugs, didn’t progress since quite some time and wasn’t easy to hack at all +(source code comments/documentation completely lacking). Still, we think the +wmii developers and contributors did a great job. Thank you for inspiring us to +create i3.

+

Please be aware that i3 is primarily targeted at advanced users and developers.

+
+
+

4.2. IMPORTANT NOTE TO nVidia BINARY DRIVER USERS

+

If you are using the nVidia binary graphics driver (also known as blob) +you need to use the --force-xinerama flag (in your .xsession) when starting +i3, like so:

+
+
+
exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
+
+

See also docs/multi-monitor for the full explanation.

+
+
+

4.3. TERMINOLOGY

+
+
+Client +
+
+

+A client is X11-speak for a window. +

+
+
+Table +
+
+

+Your workspace is managed using a table. You can move windows around and create +new columns (move a client to the right) or rows (move it to the bottom) +implicitly. +

+

By "snapping" a client in a specific direction, you increase its colspan/rowspan.

+
+
+Container +
+
+

+A container contains a variable number of clients. Each cell of the table is a +container. +

+

Containers can be used in various modes. The default mode is called "default" +and just resizes each client equally so that it fits.

+
+
+Workspace +
+
+

+A workspace is a set of clients (technically speaking, it’s just a table). +Other window managers call this "Virtual Desktops". +

+

In i3, each workspace is assigned to a specific virtual screen. By default, +screen 1 has workspace 1, screen 2 has workspace 2 and so on… However, when you +create a new workspace (by simply switching to it), it’ll be assigned the +screen you are currently on.

+
+
+Output +
+
+

+Using XRandR, you can have an X11 screen spanning multiple real monitors. +Furthermore, you can set them up in cloning mode or with positions (monitor 1 +is left of monitor 2). +

+

i3 uses the RandR API to query which outputs are available and which screens +are connected to these outputs.

+
+
+
+
+
+
+

5. KEYBINDINGS

+
+

Here is a short overview of the default keybindings:

+
+
+j/k/l/; +
+
+

+Direction keys (left, down, up, right). They are on your homerow (see the mark +on your "j" key). Alternatively, you can use the cursor keys. +

+
+
+Mod1+<direction> +
+
+

+Focus window in <direction>. +

+
+
+Mod3+<direction> +
+
+

+Focus container in <direction>. +

+
+
+Mod1+Shift+<direction> +
+
+

+Move window to <direction>. +

+
+
+Mod3+Shift+<direction> +
+
+

+Move container to <direction>. +

+
+
+Mod1+Control+<direction> +
+
+

+Snap container to <direction>. +

+
+
+Mod1+<number> +
+
+

+Switch to workspace <number>. +

+
+
+Mod1+Shift+<number> +
+
+

+Move window to workspace <number>. +

+
+
+Mod1+f +
+
+

+Toggle fullscreen mode. +

+
+
+Mod1+h +
+
+

+Enable stacking layout for the current container. +

+
+
+Mod1+e +
+
+

+Enable default layout for the current container. +

+
+
+Mod1+Shift+Space +
+
+

+Toggle tiling/floating for the current window. +

+
+
+Mod1+t +
+
+

+Select the first tiling window if the current window is floating and vice-versa. +

+
+
+Mod1+Shift+q +
+
+

+Kills the current window. This is equivalent to "clicking on the close button", +meaning a polite request to the application to close this window. For example, +Firefox will save its session upon such a request. If the application does not +support that, the window will be killed and it depends on the application what +happens. +

+
+
+Mod1+Shift+r +
+
+

+Restarts i3 in place (without losing any windows, but at this time, the layout +and placement of windows is not retained). +

+
+
+Mod1+Shift+e +
+
+

+Exits i3. +

+
+
+
+
+
+

6. FILES

+
+
+

6.1. ~/.i3/config (or ~/.config/i3/config)

+

When starting, i3 looks for configuration files in the following order:

+
    +
  1. +

    +~/.config/i3/config (or $XDG_CONFIG_HOME/i3/config if set) +

    +
    2. +
  2. +

    +/etc/xdg/i3/config (or $XDG_CONFIG_DIRS/i3/config if set) +

    +
    3. +
  3. +

    +~/.i3/config +

    +
    4. +
  4. +

    +/etc/i3/config +

    +
    5. +
+

You can specify a custom path using the -c option.

+
+
Sample configuration
+
+
font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+
+# Start terminal (Mod1+Enter)
+bind Mod1+36 exec /usr/bin/urxvt
+
+# Start dmenu (Mod1+v)
+bind Mod1+55 exec /usr/bin/dmenu_run
+
+# Kill current client (Mod1+Shift+q)
+bind Mod1+Shift+24 kill
+
+# Beamer on/off
+bind Mod1+73 exec /home/michael/toggle_beamer.sh
+
+# Screen locking
+bind Mod1+68 exec /usr/bin/i3lock
+
+# Restart i3 inplace (Mod1+Shift+r)
+bind Mod1+Shift+27 restart
+
+# Exit i3 (Mod1+Shift+e)
+bind Mod1+Shift+26 exit
+
+# Brightness
+bind Mod1+97 exec sudo sh -c "echo up > /proc/acpi/ibm/brightness"
+bind Mod1+103 exec sudo sh -c "echo down > /proc/acpi/ibm/brightness"
+
+# Fullscreen (Mod1+f)
+bind Mod1+41 f
+
+# Stacking (Mod1+h)
+bind Mod1+43 s
+
+# Default (Mod1+e)
+bind Mod1+26 d
+
+# Toggle tiling/floating of the current window (Mod1+Shift+Space)
+bind Mod1+Shift+65 t
+
+# Go into the tiling layer / floating layer, depending on whether
+# the current window is tiling / floating (Mod1+t)
+bind Mod1+28 focus ft
+
+# Focus (Mod1+j/k/l/;)
+bind Mod1+44 h
+bind Mod1+45 j
+bind Mod1+46 k
+bind Mod1+47 l
+
+# Focus Container (Mod3+j/k/l/;)
+bind Mod3+44 wch
+bind Mod3+45 wcj
+bind Mod3+46 wck
+bind Mod3+47 wcl
+
+# Snap (Mod1+Control+j/k/l/;)
+bind Mod1+Control+44 sh
+bind Mod1+Control+45 sj
+bind Mod1+Control+46 sk
+bind Mod1+Control+47 sl
+
+# Move (Mod1+Shift+j/k/l/;)
+bind Mod1+Shift+44 mh
+bind Mod1+Shift+45 mj
+bind Mod1+Shift+46 mk
+bind Mod1+Shift+47 ml
+
+# Move Container (Mod3+Shift+j/k/l/;)
+bind Mod3+Shift+44 wcmh
+bind Mod3+Shift+45 wcmj
+bind Mod3+Shift+46 wcmk
+bind Mod3+Shift+47 wcml
+
+# Workspaces
+bind Mod1+10 1
+bind Mod1+11 2
+...
+
+# Move to Workspace
+bind Mod1+Shift+10 1
+bind Mod1+Shift+11 2
+...
+
+
+
+

6.2. ~/.xsession

+

This file is where you should configure your locales and start i3. It is run by +your login manager (xdm, slim, gdm, …) as soon as you login.

+
+
Sample xsession
+
+
# Disable DPMS turning off the screen
+xset dpms force on
+xset s off
+
+# Disable bell
+xset -b
+
+# Enable zapping (C-A-<Bksp> kills X)
+setxkbmap -option terminate:ctrl_alt_bksp
+
+# Enforce correct locales from the beginning
+unset LC_COLLATE
+export LC_CTYPE=de_DE.UTF-8
+export LC_TIME=de_DE.UTF-8
+export LC_NUMERIC=de_DE.UTF-8
+export LC_MONETARY=de_DE.UTF-8
+export LC_MESSAGES=C
+export LC_PAPER=de_DE.UTF-8
+export LC_NAME=de_DE.UTF-8
+export LC_ADDRESS=de_DE.UTF-8
+export LC_TELEPHONE=de_DE.UTF-8
+export LC_MEASUREMENT=de_DE.UTF-8
+export LC_IDENTIFICATION=de_DE.UTF-8
+
+# Use XToolkit in java applications
+export AWT_TOOLKIT=XToolkit
+
+# Set background color
+xsetroot -solid "#333333"
+
+# Enable core dumps in case something goes wrong
+ulimit -c unlimited
+
+# Start i3 and log to ~/.i3/logfile
+echo "Starting at $(date)" >> ~/.i3/logfile
+exec /usr/bin/i3 -V -d all >> ~/.i3/logfile
+
+
+
+
+
+

7. TODO

+
+

There is still lot of work to do. Please check our bugtracker for up-to-date +information about tasks which are still not finished.

+
+
+
+

8. SEE ALSO

+
+

You should have a copy of the userguide (featuring nice screenshots/graphics +which is why this is not integrated into this manpage), the debugging guide, +and the "how to hack" guide. If you are building from source, run: + make -C docs

+

You can also access these documents online at http://i3.zekjur.net/

+

i3-input(1), i3-msg(1), i3-wsbar(1)

+
+
+
+

9. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/3.e/i3status.html b/docs/3.e/i3status.html new file mode 100644 index 0000000..0860168 --- /dev/null +++ b/docs/3.e/i3status.html @@ -0,0 +1,372 @@ + + + + + + +i3: i3status(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3status - Generates a status line for dzen2 or xmobar

+
+
+
+

2. SYNOPSIS

+
+

i3status [-c configfile] [-h] [-v]

+
+
+
+

3. OPTIONS

+
+
+
+-c +
+
+

+Specifies an alternate configuration file path. By default, i3status looks for +configuration files in the following order: +

+
    +
  1. +

    +~/.i3status.conf +

    +
    2. +
  2. +

    +~/.config/i3status/config (or $XDG_CONFIG_HOME/i3status/config if set) +

    +
    3. +
  3. +

    +/etc/i3status.conf +

    +
    4. +
  4. +

    +/etc/xdg/i3status/config (or $XDG_CONFIG_DIRS/i3status/config if set) +

    +
    5. +
+
+
+
+
+
+

4. DESCRIPTION

+
+

i3status is a small program (about 1500 SLOC) for generating a status bar for +i3bar, dzen2, xmobar or similar programs. It is designed to be very +efficient by issuing a very small number of system calls, as one generally +wants to update such a status line every second. This ensures that even under +high load, your status bar is updated correctly. Also, it saves a bit of energy +by not hogging your CPU as much as spawning the corresponding amount of shell +commands would.

+
+
+
+

5. CONFIGURATION

+
+

Since version 2, the configuration file for i3status will be parsed using +libconfuse. This makes configuration easier in the programmer’s point of +view and more flexible for the user at the same time.

+

The basic idea of i3status is that you can specify which "modules" should +be used (the order directive). You can then configure each module with its +own section. For every module, you can specify the output format. See below +for a complete reference.

+
+
Sample configuration
+
+
general {
+        output_format = "dzen2"
+        colors = true
+        interval = 5
+}
+
+order  = "ipv6"
+order += "disk /"
+order += "run_watch DHCP"
+order += "run_watch VPN"
+order += "wireless wlan0"
+order += "ethernet eth0"
+order += "battery 0"
+order += "cpu_temperature 0"
+order += "load"
+order += "time"
+
+wireless wlan0 {
+        format_up = "W: (%quality at %essid, %bitrate) %ip"
+        format_down = "W: down"
+}
+
+ethernet eth0 {
+        # if you use %speed, i3status requires the cap_net_admin capability
+        format_up = "E: %ip (%speed)"
+        format_down = "E: down"
+}
+
+battery 0 {
+        format = "%status %percentage %remaining"
+}
+
+run_watch DHCP {
+        pidfile = "/var/run/dhclient*.pid"
+}
+
+run_watch VPN {
+        pidfile = "/var/run/vpnc/pid"
+}
+
+time {
+        format = "%Y-%m-%d %H:%M:%S"
+}
+
+load {
+        format = "%5min"
+}
+
+cpu_temperature 0 {
+        format = "T: %degrees °C"
+        path = "/sys/devices/platform/coretemp.0/temp1_input"
+}
+
+disk "/" {
+        format = "%free"
+}
+
+
+

5.1. General

+

The colors directive will disable all colors if you set it to false. You can +also specify the colors that will be used to display "good", "degraded" or "bad" +values using the color_good, color_degraded or color_bad directives, +respectively. Those directives are only used if color support is not disabled by +the colors directive. The input format for color values is the canonical RGB +hexadecimal triplet (with no separators between the colors), prefixed by a hash +character ("#").

+

Example configuration:

+
+
+
color_good = "#00FF00"
+
+

Likewise, you can use the color_separator directive to specify the color that +will be used to paint the separator bar. The separator is always output in +color, even when colors are disabled by the colors directive.

+

The interval directive specifies the time in seconds for which i3status will +sleep before printing the next status line.

+

Using output_format you can chose which format strings i3status should +use in its output. Currently available are:

+
+
+dzen2 +
+
+

+Dzen is a general purpose messaging, notification and menuing program for X11. +It was designed to be scriptable in any language and integrate well with window +managers like dwm, wmii and xmonad though it will work with any windowmanger +

+
+
+xmobar +
+
+

+xmobar is a minimalistic, text based, status bar. It was designed to work +with the xmonad Window Manager. +

+
+
+none +
+
+

+Does not use any color codes. Separates values by the pipe symbol. This should +be used with i3bar and can be used for custom scripts. +

+
+
+
+
+

5.2. IPv6

+

This module gets the IPv6 address used for outgoing connections (that is, the +best available public IPv6 address on your computer).

+

Example format_up: %ip

+

Example format_down no IPv6

+
+
+

5.3. Disk

+

Gets used, free, available and total amount of bytes on the given mounted filesystem.

+

Example order: disk /mnt/usbstick

+

Example format: %free (%avail)/ %total

+
+
+

5.4. Run-watch

+

Expands the given path to a pidfile and checks if the process ID found inside +is valid (that is, if the process is running). You can use this to check if +a specific application, such as a VPN client or your DHCP client is running.

+

Example order: run_watch DHCP

+
+
+

5.5. Wireless

+

Gets the link quality and ESSID of the given wireless network interface. You +can specify different format strings for the network being connected or not +connected.

+

Example order: wireless wlan0

+

Example format: W: (%quality at %essid, %bitrate) %ip

+
+
+

5.6. Ethernet

+

Gets the IP address and (if possible) the link speed of the given ethernet +interface. Getting the link speed requires the cap_net_admin capability. Set +it using setcap cap_net_admin=ep $(which i3status).

+

Example order: ethernet eth0

+

Example format: E: %ip (%speed)

+
+
+

5.7. Battery

+

Gets the status (charging, discharging, running), percentage and remaining +time of the given battery. If you want to use the last full capacity instead +of the design capacity (when using the design capacity, it may happen that +your battery is at 23% when fully charged because it’s old. In general, I +want to see it this way, because it tells me how worn off my battery is.), +just specify last_full_capacity = true.

+

Example order: battery 0

+

Example format: %status %remaining

+
+
+

5.8. CPU-Temperature

+

Gets the temperature of the given thermal zone.

+

Example order: cpu_temperature 0

+

Example format: T: %degrees °C

+
+
+

5.9. CPU Usage

+

Gets the percentual CPU usage from /proc/stat.

+

Example order: cpu_usage

+

Example format: %usage

+
+
+

5.10. Load

+

Gets the system load (number of processes waiting for CPU time in the last +5, 10 and 15 minutes).

+

Example order: load

+

Example format: %5min %10min %15min

+
+
+

5.11. Time

+

Formats the current system time. See strftime(3) for the format.

+

Example order: time

+

Example format: %Y-%m-%d %H:%M:%S

+
+
+

5.12. DDate

+

Outputs the current discordian date in user-specified format. See ddate(1) for +details on the format string. +Note: Neither %. nor %X are implemented yet.

+

Example order: ddate

+

Example format: %{%a, %b %d%}, %Y%N - %H

+
+
+

5.13. Volume

+

Outputs the volume of the specified mixer on the specified device. Works only +on Linux because it uses ALSA.

+

Example order: volume master

+

Example format: ♪: %volume

+

Example configuration:

+
+
+
volume master {
+        format = "♪: %volume"
+        device = "default"
+        mixer = "Master"
+        mixer_idx = 0
+}
+
+
+
+
+
+

6. Using i3status with dzen2

+
+

After installing dzen2, you can directly use it with i3status. Just ensure that +output_format is set to dzen2.

+

Example for usage of i3status with dzen2:

+
+
+
i3status | dzen2 -fg white -ta r -w 1280 \
+-fn "-misc-fixed-medium-r-normal--13-120-75-75-C-70-iso8859-1"
+
+
+
+
+

7. Using i3status with xmobar

+
+

To get xmobar to start, you might need to copy the default configuration +file to ~/.xmobarrc. Also, ensure that the output_format option for i3status +is set to xmobar.

+

Example for usage of i3status with xmobar:

+
+
+
i3status | xmobar -o -t "%StdinReader%" -c "[Run StdinReader]"
+
+
+
+
+

8. SEE ALSO

+
+

strftime(3), date(1), glob(3), dzen2(1), xmobar(1)

+
+
+
+

9. AUTHORS

+
+

Michael Stapelberg and contributors

+

Thorsten Toepper

+

Baptiste Daroussin

+

Axel Wagner

+

Fernando Tarlá Cardoso Lemos

+
+
+
+
+ + + diff --git a/docs/3.e/ipc.html b/docs/3.e/ipc.html new file mode 100644 index 0000000..88b13b7 --- /dev/null +++ b/docs/3.e/ipc.html @@ -0,0 +1,529 @@ + + + + + + +i3: IPC interface (interprocess communication) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes how to interface with i3 from a separate process. This +is useful for example to remote-control i3 (to write test cases for example) or +to get various information like the current workspaces to implement an external +workspace bar.

+

The method of choice for IPC in our case is a unix socket because it has very +little overhead on both sides and is usually available without headaches in +most languages. In the default configuration file, no ipc-socket path is +specified and thus no socket is created. The standard path (which i3-msg and +i3-input use) is ~/.i3/ipc.sock.

+
+
+
+

1. Establishing a connection

+
+

To establish a connection, simply open the IPC socket. The following code +snippet illustrates this in Perl:

+
+
+
use IO::Socket::UNIX;
+my $sock = IO::Socket::UNIX->new(Peer => '~/.i3/ipc.sock');
+
+
+
+
+

2. Sending messages to i3

+
+

To send a message to i3, you have to format in the binary message format which +i3 expects. This format specifies a magic string in the beginning to ensure +the integrity of messages (to prevent follow-up errors). Following the magic +string comes the length of the payload of the message as 32-bit integer, and +the type of the message as 32-bit integer (the integers are not converted, so +they are in native byte order).

+

The magic string currently is "i3-ipc" and will only be changed when a change +in the IPC API is done which breaks compatibility (we hope that we don’t need +to do that).

+

Currently implemented message types are the following:

+
+
+COMMAND (0) +
+
+

+ The payload of the message is a command for i3 (like the commands you + can bind to keys in the configuration file) and will be executed + directly after receiving it. There is no reply to this message. +

+
+
+GET_WORKSPACES (1) +
+
+

+ Gets the current workspaces. The reply will be a JSON-encoded list of + workspaces (see the reply section). +

+
+
+SUBSCRIBE (2) +
+
+

+ Subscribes your connection to certain events. See [events] for a + description of this message and the concept of events. +

+
+
+GET_OUTPUTS (3) +
+
+

+ Gets the current outputs. The reply will be a JSON-encoded list of outputs + (see the reply section). +

+
+
+

So, a typical message could look like this:

+
+
+
"i3-ipc" <message length> <message type> <payload>
+
+

Or, as a hexdump:

+
+
+
00000000  69 33 2d 69 70 63 04 00  00 00 00 00 00 00 65 78  |i3-ipc........ex|
+00000010  69 74 0a                                          |it.|
+
+

To generate and send such a message, you could use the following code in Perl:

+
+
+
sub format_ipc_command {
+    my ($msg) = @_;
+    my $len;
+    # Get the real byte count (vs. amount of characters)
+    { use bytes; $len = length($msg); }
+    return "i3-ipc" . pack("LL", $len, 0) . $msg;
+}
+
+$sock->write(format_ipc_command("exit"));
+
+
+
+
+

3. Receiving replies from i3

+
+

Replies from i3 usually consist of a simple string (the length of the string +is the message_length, so you can consider them length-prefixed) which in turn +contain the JSON serialization of a data structure. For example, the +GET_WORKSPACES message returns an array of workspaces (each workspace is a map +with certain attributes).

+
+

3.1. Reply format

+

The reply format is identical to the normal message format. There also is +the magic string, then the message length, then the message type and the +payload.

+

The following reply types are implemented:

+
+
+COMMAND (0) +
+
+

+ Confirmation/Error code for the COMMAND message. +

+
+
+GET_WORKSPACES (1) +
+
+

+ Reply to the GET_WORKSPACES message. +

+
+
+SUBSCRIBE (2) +
+
+

+ Confirmation/Error code for the SUBSCRIBE message. +

+
+
+GET_OUTPUTS (3) +
+
+

+ Reply to the GET_OUTPUTS message. +

+
+
+
+
+

3.2. COMMAND reply

+

The reply consists of a single serialized map. At the moment, the only +property is success (bool), but this will be expanded in future versions.

+

Example:

+
+
+
{ "success": true }
+
+
+
+

3.3. GET_WORKSPACES reply

+

The reply consists of a serialized list of workspaces. Each workspace has the +following properties:

+
+
+num (integer) +
+
+

+ The logical number of the workspace. Corresponds to the command + to switch to this workspace. +

+
+
+name (string) +
+
+

+ The name of this workspace (by default num+1), as changed by the + user. Encoded in UTF-8. +

+
+
+visible (boolean) +
+
+

+ Whether this workspace is currently visible on an output (multiple + workspaces can be visible at the same time). +

+
+
+focused (boolean) +
+
+

+ Whether this workspace currently has the focus (only one workspace + can have the focus at the same time). +

+
+
+urgent (boolean) +
+
+

+ Whether a window on this workspace has the "urgent" flag set. +

+
+
+rect (map) +
+
+

+ The rectangle of this workspace (equals the rect of the output it + is on), consists of x, y, width, height. +

+
+
+output (string) +
+
+

+ The video output this workspace is on (LVDS1, VGA1, …). +

+
+
+

Example:

+
+
+
[
+ {
+  "num": 0,
+  "name": "1",
+  "visible": true,
+  "focused": true,
+  "urgent": false,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  },
+  "output": "LVDS1"
+ },
+ {
+  "num": 1,
+  "name": "2",
+  "visible": false,
+  "focused": false,
+  "urgent": false,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  },
+  "output": "LVDS1"
+ }
+]
+
+
+
+

3.4. SUBSCRIBE reply

+

The reply consists of a single serialized map. The only property is +success (bool), indicating whether the subscription was successful (the +default) or whether a JSON parse error occurred.

+

Example:

+
+
+
{ "success": true }
+
+
+
+

3.5. GET_OUTPUTS reply

+

The reply consists of a serialized list of outputs. Each output has the +following properties:

+
+
+name (string) +
+
+

+ The name of this output (as seen in xrandr(1)). Encoded in UTF-8. +

+
+
+active (boolean) +
+
+

+ Whether this output is currently active (has a valid mode). +

+
+
+current_workspace (integer) +
+
+

+ The current workspace which is visible on this output. null if the + output is not active. +

+
+
+rect (map) +
+
+

+ The rectangle of this output (equals the rect of the output it + is on), consists of x, y, width, height. +

+
+
+

Example:

+
+
+
[
+ {
+  "name": "LVDS1",
+  "active": true,
+  "current_workspace": 4,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  }
+ },
+ {
+  "name": "VGA1",
+  "active": true,
+  "current_workspace": 1,
+  "rect": {
+   "x": 1280,
+   "y": 0,
+   "width": 1280,
+   "height": 1024
+  },
+ }
+]
+
+
+
+
+
+

4. Events

+
+

To get informed when certain things happen in i3, clients can subscribe to +events. Events consist of a name (like "workspace") and an event reply type +(like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format +as replies to specific commands. However, the highest bit of the message type +is set to 1 to indicate that this is an event reply instead of a normal reply.

+

Caveat: As soon as you subscribe to an event, it is not guaranteed any longer +that the requests to i3 are processed in order. This means, the following +situation can happen: You send a GET_WORKSPACES request but you receive a +"workspace" event before receiving the reply to GET_WORKSPACES. If your +program does not want to cope which such kinds of race conditions (an +event based library may not have a problem here), I suggest you create a +separate connection to receive events.

+
+

4.1. Subscribing to events

+

By sending a message of type SUBSCRIBE with a JSON-encoded array as payload +you can register to an event.

+

Example:

+
+
+
type: SUBSCRIBE
+payload: [ "workspace", "focus" ]
+
+
+
+

4.2. Available events

+

The numbers in parenthesis is the event type (keep in mind that you need to +strip the highest bit first).

+
+
+workspace (0) +
+
+

+ Sent when the user switches to a different workspace, when a new + workspace is initialized or when a workspace is removed (because the + last client vanished). +

+
+
+output (1) +
+
+

+ Sent when RandR issues a change notification (of either screens, + outputs, CRTCs or output properties). +

+
+
+

Example:

+
+
+
# the appropriate 4 bytes read from the socket are stored in $input
+
+# unpack a 32-bit unsigned integer
+my $message_type = unpack("L", $input);
+
+# check if the highest bit is 1
+my $is_event = (($message_type >> 31) == 1);
+
+# use the other bits
+my $event_type = ($message_type & 0x7F);
+
+if ($is_event) {
+  say "Received event of type $event_type";
+}
+
+
+
+

4.3. workspace event

+

This event consists of a single serialized map containing a property +change (string) which indicates the type of the change ("focus", "init", +"empty", "urgent").

+

Example:

+
+
+
{ "change": "focus" }
+
+
+
+

4.4. output event

+

This event consists of a single serialized map containing a property +change (string) which indicates the type of the change (currently only +"unspecified").

+

Example:

+
+
+
{ "change": "unspecified" }
+
+
+
+
+
+

5. See also

+
+

For some languages, libraries are available (so you don’t have to implement +all this on your own). This list names some (if you wrote one, please let me +know):

+
+
+C +
+
+

+ i3 includes a headerfile i3/ipc.h which provides you all constants. + However, there is no library yet. +

+
+
+Ruby +
+
+

+ http://github.com/badboy/i3-ipc +

+
+
+Perl +
+
+

+ http://search.cpan.org/search?query=AnyEvent::I3 +

+
+
+Python +
+
+

+ http://github.com/thepub/i3ipc +

+
+
+
+
+
+
+ + + diff --git a/docs/3.e/keyboard-layer1.png b/docs/3.e/keyboard-layer1.png new file mode 100644 index 0000000..88268f7 Binary files /dev/null and b/docs/3.e/keyboard-layer1.png differ diff --git a/docs/3.e/keyboard-layer2.png b/docs/3.e/keyboard-layer2.png new file mode 100644 index 0000000..85a7d21 Binary files /dev/null and b/docs/3.e/keyboard-layer2.png differ diff --git a/docs/3.e/manpage.html b/docs/3.e/manpage.html new file mode 100644 index 0000000..80fa2ec --- /dev/null +++ b/docs/3.e/manpage.html @@ -0,0 +1,528 @@ + + + + + +i3: i3(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3 - an improved dynamic, tiling window manager

+
+
+
+

2. SYNOPSIS

+
+

i3 [-a] [-c configfile] [-C] [-d <loglevel>] [-v] [-V]

+
+
+
+

3. OPTIONS

+
+
+
+-a +
+
+

+Disables autostart. +

+
+
+-c +
+
+

+Specifies an alternate configuration file path. +

+
+
+-C +
+
+

+Check the configuration file for validity and exit. +

+
+
+-d +
+
+

+Specifies the debug loglevel. To see the most output, use -d all. +

+
+
+-v +
+
+

+Display version number (and date of the last commit). +

+
+
+-V +
+
+

+Be verbose. +

+
+
+
+
+
+

4. DESCRIPTION

+
+
+

4.1. INTRODUCTION

+

i3 was created because wmii, our favorite window manager at the time, didn’t +provide some features we wanted (multi-monitor done right, for example), had +some bugs, didn’t progress since quite some time and wasn’t easy to hack at all +(source code comments/documentation completely lacking). Still, we think the +wmii developers and contributors did a great job. Thank you for inspiring us to +create i3.

+

Please be aware that i3 is primarily targeted at advanced users and developers.

+
+
+

4.2. IMPORTANT NOTE TO nVidia BINARY DRIVER USERS

+

If you are using the nVidia binary graphics driver (also known as blob) +you need to use the --force-xinerama flag (in your .xsession) when starting +i3, like so:

+
+
+
exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
+
+

See also docs/multi-monitor for the full explanation.

+
+
+

4.3. TERMINOLOGY

+
+
+Client +
+
+

+A client is X11-speak for a window. +

+
+
+Table +
+
+

+Your workspace is managed using a table. You can move windows around and create +new columns (move a client to the right) or rows (move it to the bottom) +implicitly. +

+

By "snapping" a client in a specific direction, you increase its colspan/rowspan.

+
+
+Container +
+
+

+A container contains a variable number of clients. Each cell of the table is a +container. +

+

Containers can be used in various modes. The default mode is called "default" +and just resizes each client equally so that it fits.

+
+
+Workspace +
+
+

+A workspace is a set of clients (technically speaking, it’s just a table). +Other window managers call this "Virtual Desktops". +

+

In i3, each workspace is assigned to a specific virtual screen. By default, +screen 1 has workspace 1, screen 2 has workspace 2 and so on… However, when you +create a new workspace (by simply switching to it), it’ll be assigned the +screen you are currently on.

+
+
+Output +
+
+

+Using XRandR, you can have an X11 screen spanning multiple real monitors. +Furthermore, you can set them up in cloning mode or with positions (monitor 1 +is left of monitor 2). +

+

i3 uses the RandR API to query which outputs are available and which screens +are connected to these outputs.

+
+
+
+
+
+
+

5. KEYBINDINGS

+
+

Here is a short overview of the default keybindings:

+
+
+j/k/l/; +
+
+

+Direction keys (left, down, up, right). They are on your homerow (see the mark +on your "j" key). Alternatively, you can use the cursor keys. +

+
+
+Mod1+<direction> +
+
+

+Focus window in <direction>. +

+
+
+Mod3+<direction> +
+
+

+Focus container in <direction>. +

+
+
+Mod1+Shift+<direction> +
+
+

+Move window to <direction>. +

+
+
+Mod3+Shift+<direction> +
+
+

+Move container to <direction>. +

+
+
+Mod1+Control+<direction> +
+
+

+Snap container to <direction>. +

+
+
+Mod1+<number> +
+
+

+Switch to workspace <number>. +

+
+
+Mod1+Shift+<number> +
+
+

+Move window to workspace <number>. +

+
+
+Mod1+f +
+
+

+Toggle fullscreen mode. +

+
+
+Mod1+h +
+
+

+Enable stacking layout for the current container. +

+
+
+Mod1+e +
+
+

+Enable default layout for the current container. +

+
+
+Mod1+Shift+Space +
+
+

+Toggle tiling/floating for the current window. +

+
+
+Mod1+t +
+
+

+Select the first tiling window if the current window is floating and vice-versa. +

+
+
+Mod1+Shift+q +
+
+

+Kills the current window. This is equivalent to "clicking on the close button", +meaning a polite request to the application to close this window. For example, +Firefox will save its session upon such a request. If the application does not +support that, the window will be killed and it depends on the application what +happens. +

+
+
+Mod1+Shift+r +
+
+

+Restarts i3 in place (without losing any windows, but at this time, the layout +and placement of windows is not retained). +

+
+
+Mod1+Shift+e +
+
+

+Exits i3. +

+
+
+
+
+
+

6. FILES

+
+
+

6.1. ~/.i3/config (or ~/.config/i3/config)

+

When starting, i3 looks for configuration files in the following order:

+
    +
  1. +

    +~/.config/i3/config (or $XDG_CONFIG_HOME/i3/config if set) +

    +
    2. +
  2. +

    +/etc/xdg/i3/config (or $XDG_CONFIG_DIRS/i3/config if set) +

    +
    3. +
  3. +

    +~/.i3/config +

    +
    4. +
  4. +

    +/etc/i3/config +

    +
    5. +
+

You can specify a custom path using the -c option.

+
+
Sample configuration
+
+
font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+
+# Start terminal (Mod1+Enter)
+bind Mod1+36 exec /usr/bin/urxvt
+
+# Start dmenu (Mod1+v)
+bind Mod1+55 exec /usr/bin/dmenu_run
+
+# Kill current client (Mod1+Shift+q)
+bind Mod1+Shift+24 kill
+
+# Beamer on/off
+bind Mod1+73 exec /home/michael/toggle_beamer.sh
+
+# Screen locking
+bind Mod1+68 exec /usr/bin/i3lock
+
+# Restart i3 inplace (Mod1+Shift+r)
+bind Mod1+Shift+27 restart
+
+# Exit i3 (Mod1+Shift+e)
+bind Mod1+Shift+26 exit
+
+# Brightness
+bind Mod1+97 exec sudo sh -c "echo up > /proc/acpi/ibm/brightness"
+bind Mod1+103 exec sudo sh -c "echo down > /proc/acpi/ibm/brightness"
+
+# Fullscreen (Mod1+f)
+bind Mod1+41 f
+
+# Stacking (Mod1+h)
+bind Mod1+43 s
+
+# Default (Mod1+e)
+bind Mod1+26 d
+
+# Toggle tiling/floating of the current window (Mod1+Shift+Space)
+bind Mod1+Shift+65 t
+
+# Go into the tiling layer / floating layer, depending on whether
+# the current window is tiling / floating (Mod1+t)
+bind Mod1+28 focus ft
+
+# Focus (Mod1+j/k/l/;)
+bind Mod1+44 h
+bind Mod1+45 j
+bind Mod1+46 k
+bind Mod1+47 l
+
+# Focus Container (Mod3+j/k/l/;)
+bind Mod3+44 wch
+bind Mod3+45 wcj
+bind Mod3+46 wck
+bind Mod3+47 wcl
+
+# Snap (Mod1+Control+j/k/l/;)
+bind Mod1+Control+44 sh
+bind Mod1+Control+45 sj
+bind Mod1+Control+46 sk
+bind Mod1+Control+47 sl
+
+# Move (Mod1+Shift+j/k/l/;)
+bind Mod1+Shift+44 mh
+bind Mod1+Shift+45 mj
+bind Mod1+Shift+46 mk
+bind Mod1+Shift+47 ml
+
+# Move Container (Mod3+Shift+j/k/l/;)
+bind Mod3+Shift+44 wcmh
+bind Mod3+Shift+45 wcmj
+bind Mod3+Shift+46 wcmk
+bind Mod3+Shift+47 wcml
+
+# Workspaces
+bind Mod1+10 1
+bind Mod1+11 2
+...
+
+# Move to Workspace
+bind Mod1+Shift+10 1
+bind Mod1+Shift+11 2
+...
+
+
+
+

6.2. ~/.xsession

+

This file is where you should configure your locales and start i3. It is run by +your login manager (xdm, slim, gdm, …) as soon as you login.

+
+
Sample xsession
+
+
# Disable DPMS turning off the screen
+xset dpms force on
+xset s off
+
+# Disable bell
+xset -b
+
+# Enable zapping (C-A-<Bksp> kills X)
+setxkbmap -option terminate:ctrl_alt_bksp
+
+# Enforce correct locales from the beginning
+unset LC_COLLATE
+export LC_CTYPE=de_DE.UTF-8
+export LC_TIME=de_DE.UTF-8
+export LC_NUMERIC=de_DE.UTF-8
+export LC_MONETARY=de_DE.UTF-8
+export LC_MESSAGES=C
+export LC_PAPER=de_DE.UTF-8
+export LC_NAME=de_DE.UTF-8
+export LC_ADDRESS=de_DE.UTF-8
+export LC_TELEPHONE=de_DE.UTF-8
+export LC_MEASUREMENT=de_DE.UTF-8
+export LC_IDENTIFICATION=de_DE.UTF-8
+
+# Use XToolkit in java applications
+export AWT_TOOLKIT=XToolkit
+
+# Set background color
+xsetroot -solid "#333333"
+
+# Enable core dumps in case something goes wrong
+ulimit -c unlimited
+
+# Start i3 and log to ~/.i3/logfile
+echo "Starting at $(date)" >> ~/.i3/logfile
+exec /usr/bin/i3 -V -d all >> ~/.i3/logfile
+
+
+
+
+
+

7. TODO

+
+

There is still lot of work to do. Please check our bugtracker for up-to-date +information about tasks which are still not finished.

+
+
+
+

8. SEE ALSO

+
+

You should have a copy of the userguide (featuring nice screenshots/graphics +which is why this is not integrated into this manpage), the debugging guide, +and the "how to hack" guide. If you are building from source, run: + make -C docs

+

You can also access these documents online at http://i3.zekjur.net/

+

i3-input(1), i3-msg(1), i3-wsbar(1)

+
+
+
+

9. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/3.e/modes.png b/docs/3.e/modes.png new file mode 100644 index 0000000..656a6db Binary files /dev/null and b/docs/3.e/modes.png differ diff --git a/docs/3.e/multi-monitor.html b/docs/3.e/multi-monitor.html new file mode 100644 index 0000000..ee42703 --- /dev/null +++ b/docs/3.e/multi-monitor.html @@ -0,0 +1,108 @@ + + + + + + +i3: The multi-monitor situation + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

…or: oh no, I have an nVidia graphics card!

+
+
+
+

1. The quick fix

+
+

If you are using the nVidia binary graphics driver (also known as blob) +you need to use the --force-xinerama flag (in your .xsession) when starting +i3, like so:

+
+
Example:
+
+
exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
+
+
+
+
+

2. The explanation

+
+

Starting with version 3.ε, i3 uses the RandR (Rotate and Resize) API instead +of Xinerama. The reason for this, is that RandR provides more information +about your outputs and connected screens than Xinerama does. To be specific, +the code which handled on-the-fly screen reconfiguration (meaning without +restarting the X server) was a very messy heuristic and most of the time did +not work correctly — that is just not possible with the little information +Xinerama offers (just a list of screen resolutions, no identifiers for the +screens or any additional information). Xinerama simply was not designed +for dynamic configuration.

+

So RandR came along, as a more powerful alternative (RandR 1.2 to be specific). +It offers all of Xinerama’s possibilities and lots more. Using the RandR API +made our code much more robust and clean. Also, you can now reliably assign +workspaces to output names instead of some rather unreliable screen identifier +(position inside the list of screens, which could change, and so on…).

+

As RandR has been around for about three years as of this writing, it seemed +like a very good idea to us, and it still is a very good one. What we did not +expect, however, was the nVidia binary driver. It still does not support RandR +(as of March 2010), even though nVidia has announced that it will support RandR +eventually. What does this mean for you, if you are stuck with the binary +driver for some reason (say the free drivers don’t work with your card)? First +of all, you are stuck with TwinView and cannot use xrandr. While this ruins +the user experience, the more grave problem is that the nVidia driver not only +does not support dynamic configuration using RandR, it also does not expose +correct multi-monitor information via the RandR API. So, in some setups, i3 +will not find any screens; in others, it will find one large screen which +actually contains both of your physical screens (but it will not know that +these are two screens).

+

For this very reason, we decided to implement the following workaround: As +long as the nVidia driver does not support RandR, an option called +--force-xinerama is available in i3. This option gets the list of screens +once when starting, and never updates it. As the nVidia driver cannot do +dynamic configuration anyways, this is not a big deal.

+
+
+
+

3. See also

+
+

For more information on how to use multi-monitor setups, see the i3 User’s +Guide.

+
+
+
+
+ + + diff --git a/docs/3.e/refcard.pdf b/docs/3.e/refcard.pdf new file mode 100644 index 0000000..f1bb36f Binary files /dev/null and b/docs/3.e/refcard.pdf differ diff --git a/docs/3.e/repositories.html b/docs/3.e/repositories.html new file mode 100644 index 0000000..db62780 --- /dev/null +++ b/docs/3.e/repositories.html @@ -0,0 +1,120 @@ + + + + + + +i3: Debian and Ubuntu repositories + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. When should you use our repositories?

+
+

In general, you should use the repositories of your distribution. Adding +third-party repositories to your /etc/sources.list has security implications +and makes your apt-get update take longer. However, in some cases, using our +repositories makes sense:

+
+
+You are using Debian stable +
+
+

+ The latest version of i3 will be in Debian testing quite soon. The version + in Debian stable can be old, however (we cannot update it after stable has + been released). The best way is to add Debian testing and tell apt to + prefer Debian stable. You should not use our repository. +

+
+
+You are using Ubuntu +
+
+

+ Only a handful of packages are maintained by Ubuntu developers. The rest is + synchronized periodically from Debian, every 6 months. Therefore, Ubuntu + often includes old versions of i3. You should use our Ubuntu repository. +

+
+
+You want the latest i3 development version +
+
+

+ If you are using Debian (Debian-derived systems might work, too) and want + the latest development version of i3, you should use our Debian repository. +

+
+
+
+
+
+

2. Ubuntu repository

+
+

The Ubuntu repository is provided by sur5r and contains the latest stable release +of i3. To use it, run the following commands:

+
+
+
# echo 'deb http://debian.sur5r.net/i3/ natty universe' >> /etc/apt/sources.list
+# apt-get update
+# apt-get install i3
+
+

The following Ubuntu versions are currently available: lucid, maverick, natty.

+
+
+
+

3. Debian repository

+
+

Our Debian repository contains packages which are automatically built a few +minutes after every commit. To use it, run the following commands:

+
+
+
# echo 'deb http://build.i3wm.org/debian/i3-wm sid main' >> /etc/apt/sources.list
+# apt-get update
+# apt-get install i3-wm
+
+

To ensure that the autobuilt i3 packages will be preferred to the packages of +your distribution, put the following entry at the beginning of your +/etc/apt/preferences:

+
+
+
Package: *
+Pin: origin "build.i3wm.org"
+Pin-Priority: 1001
+
+

Then, install i3-wm.

+
+
+
+
+ + + diff --git a/docs/3.e/single_terminal.png b/docs/3.e/single_terminal.png new file mode 100644 index 0000000..4fe918c Binary files /dev/null and b/docs/3.e/single_terminal.png differ diff --git a/docs/3.e/snapping.png b/docs/3.e/snapping.png new file mode 100644 index 0000000..65fe6e4 Binary files /dev/null and b/docs/3.e/snapping.png differ diff --git a/docs/3.e/stacklimit.png b/docs/3.e/stacklimit.png new file mode 100644 index 0000000..ab5bed7 Binary files /dev/null and b/docs/3.e/stacklimit.png differ diff --git a/docs/3.e/tree-layout1.png b/docs/3.e/tree-layout1.png new file mode 100644 index 0000000..ee69f1a Binary files /dev/null and b/docs/3.e/tree-layout1.png differ diff --git a/docs/3.e/tree-layout2.png b/docs/3.e/tree-layout2.png new file mode 100644 index 0000000..5cbadde Binary files /dev/null and b/docs/3.e/tree-layout2.png differ diff --git a/docs/3.e/tree-migrating.html b/docs/3.e/tree-migrating.html new file mode 100644 index 0000000..9949384 --- /dev/null +++ b/docs/3.e/tree-migrating.html @@ -0,0 +1,269 @@ + + + + + + +i3: Tree branch: Migrating + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. Introduction

+
+

The tree branch (referring to a branch of i3 in the git repository) is the new +version of i3. Due to the very deep changes and heavy refactoring of the source +source, we decided to develop it in a seperate branch (instead of using the +next/master-branch system like before).

+
+
+
+

2. Current status

+
+

Currently, the code is mostly working. Some of the i3 core developers have been +using the tree branch version for a few weeks now. So, if you are eager to try +out the new features and help us find bugs, give it a try!

+

At the same time, a word of warning is appropriate: This version of i3 might +crash unexpectedly, so please be careful with important data (do not work for +two days without saving…).

+
+
+
+

3. Getting the latest tree branch version

+
+

Check out the latest version:

+
+
+
$ git clone -b tree git://code.stapelberg.de/i3
+
+

Then build and install it (has the same dependencies as the latest stable i3 +version):

+
+
+
$ cd i3
+$ make
+$ sudo cp i3 /usr/bin/i3-tree
+
+

…and execute i3-tree instead of i3 in your Xsession.

+

IMPORTANT: Please note that configuration file compatibility is not yet done. +So, make sure you use/customize the provided i3.config file.

+
+
+
+

4. Tree

+
+

The most important change and reason for the name is that i3 stores all +information about the X11 outputs, workspaces and layout of the windows on them +in a tree. The root node is the X11 root window, followed by the X11 outputs, +then workspaces and finally the windows themselve. In previous versions of i3 +we had multiple lists (of outputs, workspaces) and a table for each workspace. +That approach turned out to be complicated to use (snapping), understand and +implement.

+
+

4.1. The tree consists of Containers

+

The building blocks of our tree are so called Containers. A Container can +host a window (meaning an X11 window, one that you can actually see and use, +like a browser). Alternatively, it could contain one or more Containers. A +simple example is the workspace: When you start i3 with a single monitor, a +single workspace and you open two terminal windows, you will end up with a tree +like this:

+
+
+layout2 +
+
+
+
+shot4 +
+
Figure 1. Two terminals on standard workspace
+
+
+
+

4.2. Orientation and Split Containers

+

It is only natural to use so-called Split Containers in order to build a +layout when using a tree as data structure. In i3, every Container has an +orientation (horizontal, vertical or unspecified). So, in our example with the +workspace, the default orientation of the workspace Container is horizontal +(most monitors are widescreen nowadays). If you change the orientation to +vertical (Alt+v in the default config) and then open two terminals, i3 will +configure your windows like this:

+
+
+shot2 +
+
Figure 2. Vertical Workspace Orientation
+
+

An interesting new feature of the tree branch is the ability to split anything: +Let’s assume you have two terminals on a workspace (with horizontal +orientation), focus is on the right terminal. Now you want to open another +terminal window below the current one. If you would just open a new terminal +window, it would show up to the right due to the horizontal workspace +orientation. Instead, press Alt+v to create a Vertical Split Container (to +open a Horizontal Split Container, use Alt+h). Now you can open a new +terminal and it will open below the current one:

+
+
+Layout +
+
+
+
+shot +
+
Figure 3. Vertical Split Container
+
+
+

You probably guessed it already: There is no limit on how deep your hierarchy +of splits can be.

+
+
+

4.3. Level up

+

Let’s stay with our example from above. We have a terminal on the left and two +vertically split terminals on the right, focus is on the bottom right one. When +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 level up, 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:

+
+
+shot3 +
+
Figure 4. Level Up, then open new terminal
+
+
+
+
+
+

5. Commands

+
+

The authoritive reference for commands is src/cmdparse.y. You can also find +most commands in i3.config. Here comes a short overview over the important +commands:

+
+

5.1. Manipulating layout

+
+
+
layout <default|stacked|tabbed>
+
+
+
+

5.2. Changing Focus

+
+
+
next <horizontal|vertical>
+prev <horizontal|vertical>
+
+
+
Examples:
+
+
bindsym Mod1+Left prev h
+bindsym Mod1+Right next h
+bindsym Mod1+Down next v
+bindsym Mod1+Up prev v
+
+
+
+

5.3. Moving

+
+
+
move <before|after> <horizontal|vertical>
+
+
+
Examples:
+
+
bindsym Mod1+Shift+Left move before h
+bindsym Mod1+Shift+Right move after h
+bindsym Mod1+Shift+Down move before v
+bindsym Mod1+Shift+Up move after v
+
+
+
+

5.4. Changing workspace

+
+
+
workspace <name>
+
+
+
Examples:
+
+
bindsym Mod1+1 workspace 1
+bindsym Mod1+2 workspace 2
+…
+
+
+
+

5.5. Moving Containers to workspaces

+
+
+
move workspace <name>
+
+
+
+
bindsym Mod1+Shift+1 move workspace 1
+bindsym Mod1+Shift+2 move workspace 2
+…
+
+
+
+

5.6. Changing border style

+
+
+
border <normal|none|1pixel>
+
+
+
+

5.7. Changing container mode

+
+
+
mode <tiling|floating|toggle>
+
+
+
+
+
+

6. The rest

+
+

What is not mentioned here explicitly is either unchanged and can be read in +the i3 User’s Guide or it is not yet +implemented.

+
+
+
+
+ + + diff --git a/docs/3.e/tree-shot1.png b/docs/3.e/tree-shot1.png new file mode 100644 index 0000000..3bbeae1 Binary files /dev/null and b/docs/3.e/tree-shot1.png differ diff --git a/docs/3.e/tree-shot2.png b/docs/3.e/tree-shot2.png new file mode 100644 index 0000000..f003264 Binary files /dev/null and b/docs/3.e/tree-shot2.png differ diff --git a/docs/3.e/tree-shot3.png b/docs/3.e/tree-shot3.png new file mode 100644 index 0000000..fe4c11e Binary files /dev/null and b/docs/3.e/tree-shot3.png differ diff --git a/docs/3.e/tree-shot4.png b/docs/3.e/tree-shot4.png new file mode 100644 index 0000000..61e8c91 Binary files /dev/null and b/docs/3.e/tree-shot4.png differ diff --git a/docs/3.e/two_columns.png b/docs/3.e/two_columns.png new file mode 100644 index 0000000..6dc8c40 Binary files /dev/null and b/docs/3.e/two_columns.png differ diff --git a/docs/3.e/two_terminals.png b/docs/3.e/two_terminals.png new file mode 100644 index 0000000..20b45ac Binary files /dev/null and b/docs/3.e/two_terminals.png differ diff --git a/docs/3.e/userguide.html b/docs/3.e/userguide.html new file mode 100644 index 0000000..bfb4d63 --- /dev/null +++ b/docs/3.e/userguide.html @@ -0,0 +1,1128 @@ + + + + + + +i3: i3 User’s Guide + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document contains all the information you need to configure and use the i3 +window manager. If it does not, please contact me on IRC, Jabber or E-Mail and +I’ll help you out.

+
+
+
+

1. Default keybindings

+
+

For the "too long; didn’t read" people, here is an overview of the default +keybindings (click to see the full size image):

+

Keys to use with Mod1 (alt):

+

+ +Keys to use with Mod1 (alt) + +

+

Keys to use with Shift+Mod1:

+

+ +Keys to use with Shift+Mod1 + +

+

As i3 uses keycodes in the default configuration, it does not matter which +keyboard layout you actually use. The key positions are what matters (of course +you can also use keysymbols, see [keybindings]).

+

The red keys are the modifiers you need to press (by default), the blue keys +are your homerow.

+
+
+
+

2. Using i3

+
+
+

2.1. Opening terminals and moving around

+

One very basic operation is opening a new terminal. By default, the keybinding +for this is Mod1+Enter, that is Alt+Enter in the default configuration. By +pressing Mod1+Enter, a new terminal will be opened. It will fill the whole +space available on your screen.

+

+Single terminal +

+

It is important to keep in mind that i3 uses a table to manage your windows. At +the moment, you have exactly one column and one row which leaves you with one +cell. In this cell there is a container, which is where your new terminal is +opened.

+

If you now open another terminal, you still have only one cell. However, the +container in that cell holds both of your terminals. So, a container is just a +group of clients with a specific layout. Containers can be resized by adjusting +the size of the cell that holds them.

+

+Two terminals +

+

To move the focus between the two terminals, you use the direction keys which +you may know from the editor vi. However, in i3, your homerow is used for +these keys (in vi, the keys are shifted to the left by one for compatibility +with most keyboard layouts). Therefore, Mod1+J is left, Mod1+K is down, +Mod1+L is up and Mod1+; is right. So, to switch between the terminals, +use Mod1+K or Mod1+L.

+

To create a new row/column (and a new cell), you can simply move a terminal (or +any other window) in the direction you want to expand your table. So, let’s +expand the table to the right by pressing Mod1+Shift+;.

+

+Two columns +

+
+
+

2.2. Changing container modes

+

A container can have the following modes:

+
+
+default +
+
+

+Windows are sized so that every window gets an equal amount of space in the +container. +

+
+
+stacking +
+
+

+Only the focused window in the container is displayed. You get a list of +windows at the top of the container. +

+
+
+tabbed +
+
+

+The same principle as stacking, but the list of windows at the top is only +a single line which is vertically split. +

+
+
+

To switch modes, press Mod1+e for default, Mod1+h for stacking and +Mod1+w for tabbed.

+

+Container modes +

+
+
+

2.3. Toggling fullscreen mode for a window

+

To display a window fullscreen or to go out of fullscreen mode again, press +Mod1+f.

+

There is also a global fullscreen mode in i3 in which the client will use all +available outputs. To use it, or to get out of it again, press Mod1+Shift+f.

+
+
+

2.4. Opening other applications

+

Aside from opening applications from a terminal, you can also use the handy +dmenu which is opened by pressing Mod1+v by default. Just type the name +(or a part of it) of the application which you want to open. The application +typed has to be in your $PATH for this to work.

+

Additionally, if you have applications you open very frequently, you can +create a keybinding for starting the application directly. See the section +"Configuring i3" for details.

+
+
+

2.5. Closing windows

+

If an application does not provide a mechanism for closing (most applications +provide a menu, the escape key or a shortcut like Control+W to close), you +can press Mod1+Shift+q to kill a window. For applications which support +the WM_DELETE protocol, this will correctly close the application (saving +any modifications or doing other cleanup). If the application doesn’t support +the WM_DELETE protocol your X server will kill the window and the behaviour +depends on the application.

+
+
+

2.6. Using workspaces

+

Workspaces are an easy way to group a set of windows. By default, you are on +the first workspace, as the bar on the bottom left indicates. To switch to +another workspace, press Mod1+num where num is the number of the workspace +you want to use. If the workspace does not exist yet, it will be created.

+

A common paradigm is to put the web browser on one workspace, communication +applications (mutt, irssi, …) on another one, and the ones with which you +work, on the third one. Of course, there is no need to follow this approach.

+

If you have multiple screens, a workspace will be created on each screen at +startup. If you open a new workspace, it will be bound to the screen you +created it on. When you switch to a workspace on another screen, i3 will set +focus to that screen.

+
+
+

2.7. Moving windows to workspaces

+

To move a window to another workspace, simply press Mod1+Shift+num where +num is (like when switching workspaces) the number of the target workspace. +Similarly to switching workspaces, the target workspace will be created if +it does not yet exist.

+
+
+

2.8. Resizing columns/rows

+

To resize columns or rows, just grab the border between the two columns/rows +and move it to the wanted size. Please keep in mind that each cell of the table +holds a container and thus you cannot horizontally resize single windows. If +you need applications with different horizontal sizes, place them in seperate +cells one above the other.

+

See [resizingconfig] for how to configure i3 to be able to resize +columns/rows with your keyboard.

+
+
+

2.9. Restarting i3 inplace

+

To restart i3 inplace (and thus get into a clean state if there is a bug, or +to upgrade to a newer version of i3) you can use Mod1+Shift+r. Be aware, +though, that this kills your current layout and all the windows you have opened +will be put in a default container in only one cell. Saving layouts will be +implemented in a later version.

+
+
+

2.10. Exiting i3

+

To cleanly exit i3 without killing your X server, you can use Mod1+Shift+e.

+
+
+

2.11. Snapping

+

Snapping is a mechanism to increase/decrease the colspan/rowspan of a container. +Colspan/rowspan is the number of columns/rows a specific cell of the table +consumes. This is easier explained by giving an example, so take the following +layout:

+

+Snapping example +

+

To use the full size of your screen, you can now snap container 3 downwards +by pressing Mod1+Control+k (or snap container 2 rightwards).

+
+
+

2.12. Floating

+

Floating mode is the opposite of tiling mode. The position and size of a window +are not managed by i3, but by you. Using this mode violates the tiling +paradigm but can be useful for some corner cases like "Save as" dialog +windows, or toolbar windows (GIMP or similar).

+

You can enable floating mode for a window by pressing Mod1+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].

+

For resizing floating windows with your keyboard, see [resizingconfig].

+

Floating windows are always on top of tiling windows.

+
+
+
+
+

3. Configuring i3

+
+

This is where the real fun begins ;-). Most things are very dependant on your +ideal working environment so we can’t make reasonable defaults for them.

+

While not using a programming language for the configuration, i3 stays +quite flexible in regards to the things you usually want your window manager +to do.

+

For example, you can configure bindings to jump to specific windows, +you can set specific applications to start on specific workspaces, you can +automatically start applications, you can change the colors of i3, and you +can bind your keys to do useful things.

+

To change the configuration of i3, copy /etc/i3/config to ~/.i3/config +(or ~/.config/i3/config if you like the XDG directory scheme) and edit it +with a text editor.

+
+

3.1. Comments

+

It is possible and recommended to use comments in your configuration file to +properly document your setup for later reference. Comments are started with +a # and can only be used at the beginning of a line:

+

Examples:

+
+
+
# This is a comment
+
+
+
+

3.2. Fonts

+

i3 uses X core fonts (not Xft) for rendering window titles and the internal +workspace bar. You can use xfontsel(1) to generate such a font description. +To see special characters (Unicode), you need to use a font which supports +the ISO-10646 encoding.

+

Syntax:

+
+
+
font <X core font description>
+
+

Examples:

+
+
+
font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+
+
+
+

3.3. Keyboard bindings

+

A keyboard binding makes i3 execute a command (see below) upon pressing a +specific key. i3 allows you to bind either on keycodes or on keysyms (you can +also mix your bindings, though i3 will not protect you from overlapping ones).

+
    +
  • +

    +A keysym (key symbol) is a description for a specific symbol, like "a" + or "b", but also more strange ones like "underscore" instead of "_". These + are the ones you use in Xmodmap to remap your keys. To get the current + mapping of your keys, use xmodmap -pke. +

    +
    • +
  • +

    +Keycodes do not need to have a symbol assigned (handy for some hotkeys + on some notebooks) and they will not change their meaning as you switch to a + different keyboard layout (when using xmodmap). +

    +
    • +
+

My recommendation is: If you often switch keyboard layouts but you want to keep +your bindings in the same physical location on the keyboard, use keycodes. +If you don’t switch layouts, and want a clean and simple config file, use +keysyms.

+

Syntax:

+
+
+
bindsym [Modifiers+]keysym command
+bind [Modifiers+]keycode command
+
+

Examples:

+
+
+
# Fullscreen
+bindsym Mod1+f f
+
+# Restart
+bindsym Mod1+Shift+r restart
+
+# Notebook-specific hotkeys
+bind 214 exec /home/michael/toggle_beamer.sh
+
+

Available Modifiers:

+
+
+Mod1-Mod5, Shift, Control +
+
+

+Standard modifiers, see xmodmap(1) +

+
+
+Mode_switch +
+
+

+Unlike other window managers, i3 can use Mode_switch as a modifier. This allows +you to remap capslock (for example) to Mode_switch and use it for both: typing +umlauts or special characters and having some comfortably reachable key +bindings. For example, when typing, capslock+1 or capslock+2 for switching +workspaces is totally convenient. Try it :-). +

+
+
+
+
+

3.4. The floating modifier

+

To move floating windows with your mouse, you can either grab their titlebar +or configure the so called floating modifier which you can then press and +click anywhere in the window itself to move it. The most common setup is to +use the same key you use for managing windows (Mod1 for example). Then +you can press Mod1, click into a window using your left mouse button, and drag +it to the position you want.

+

When holding the floating modifier, you can resize a floating window by +pressing the right mouse button on it and moving around while holding it. If +you hold the shift button as well, the resize will be proportional.

+

Syntax:

+
+
+
floating_modifier <Modifiers>
+
+

Examples:

+
+
+
floating_modifier Mod1
+
+
+
+

3.5. Layout mode for new containers

+

This option determines in which mode new containers will start. See also +[stack-limit].

+

Syntax:

+
+
+
new_container <default|stacking|tabbed>
+new_container stack-limit <cols|rows> <value>
+
+

Examples:

+
+
+
new_container tabbed
+
+
+
+

3.6. Border style for new windows

+

This option determines which border style new windows will have.

+

Syntax:

+
+
+
new_window <bp|bn|bb>
+
+

Examples:

+
+
+
new_window bp
+
+
+
+

3.7. Variables

+

As you learned in the section about keyboard bindings, you will have +to configure lots of bindings containing modifier keys. If you want to save +yourself some typing and be able to change the modifier you use later, +variables can be handy.

+

Syntax:

+
+
+
set name value
+
+

Examples:

+
+
+
set $m Mod1
+bindsym $m+Shift+r restart
+
+

Variables are directly replaced in the file when parsing. There is no fancy +handling and there are 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).

+
+
+

3.8. Automatically putting clients on specific workspaces

+

It is recommended that you match on window classes wherever 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]
+
+

Examples:

+
+
+
assign urxvt 2
+assign urxvt → 2
+assign "urxvt" → 2
+assign "urxvt/VIM" → 3
+assign "gecko" → ~4
+assign "xv/MPlayer" → ~
+
+

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.

+
+
+

3.9. Automatically starting applications on i3 startup

+

By using the exec keyword outside a keybinding, you can configure which +commands will be performed by i3 on initial startup (not when restarting i3 +in-place however). These commands will be run in order.

+

Syntax:

+
+
+
exec command
+
+

Examples:

+
+
+
exec sudo i3status | dzen2 -dock
+
+
+
+

3.10. Automatically putting workspaces on specific screens

+

If you assign clients to workspaces, it might be handy to put the +workspaces on specific screens. Also, the assignment of workspaces to screens +will determine which workspace i3 uses for a new screen when adding screens +or when starting (e.g., by default it will use 1 for the first screen, 2 for +the second screen and so on).

+

Syntax:

+
+
+
workspace <number> output <output>
+
+

The output is the name of the RandR output you attach your screen to. On a +laptop, you might have VGA1 and LVDS1 as output names. You can see the +available outputs by running xrandr --current.

+

Examples:

+
+
+
workspace 1 output LVDS1
+workspace 5 output VGA1
+
+
+
+

3.11. Named workspaces

+

If you always have a certain arrangement of workspaces, you might want to give +them names (of course UTF-8 is supported):

+

Syntax:

+
+
+
workspace <number> <name>
+workspace <number> output <output> name
+
+

For more details about the output part of this command, see above.

+

Examples:

+
+
+
workspace 1 www
+workspace 2 work
+workspace 3 i ♥ workspaces
+
+
+
+

3.12. Changing colors

+

You can change all colors which i3 uses to draw the window decorations and the +bottom bar.

+

Syntax:

+
+
+
colorclass border background text
+
+

Where colorclass can be one of:

+
+
+client.focused +
+
+

+ A client which currently has the focus. +

+
+
+client.focused_inactive +
+
+

+ A client which is the focused one of its container, but it does not have + the focus at the moment. +

+
+
+client.unfocused +
+
+

+ A client which is not the focused one of its container. +

+
+
+client.urgent +
+
+

+ A client which has its urgency hint activated. +

+
+
+bar.focused +
+
+

+ The current workspace in the bottom bar. +

+
+
+bar.unfocused +
+
+

+ All other workspaces in the bottom bar. +

+
+
+bar.urgent +
+
+

+ A workspace which has at least one client with an activated urgency hint. +

+
+
+

You can also specify the color to be used to paint the background of the client +windows. This color will be used to paint the window on top of which the client +will be rendered.

+

Syntax:

+
+
+
client.background color
+
+

Only clients that do not cover the whole area of this window expose the color +used to paint it. If you use a color other than black for your terminals, you +most likely want to set the client background color to the same color as your +terminal program’s background color to avoid black gaps between the rendered +area of the termianal and the i3 border.

+

Colors are in HTML hex format (#rrggbb), see the following example:

+

Examples:

+
+
+
# class        border  backgr. text
+client.focused #2F343A #900000 #FFFFFF
+
+

Note that for the window decorations, the color around the child window is the +background color, and the border color is only the two thin lines at the top of +the window.

+
+
+

3.13. Interprocess communication

+

i3 uses unix sockets to provide an IPC interface. This allows third-party +programs to get information from i3, such as the current workspaces +(to display a workspace bar), and to control i3.

+

To enable it, you have to configure a path where the unix socket will be +stored. The default path is ~/.i3/ipc.sock.

+

Examples:

+
+
+
ipc-socket ~/.i3/ipc.sock
+
+

You can then use the i3-msg application to perform any command listed in +the next section.

+
+
+

3.14. Disable focus follows mouse

+

If you have a setup where your mouse usually is in your way (like a touchpad +on your laptop which you do not want to disable completely), you might want +to disable focus follows mouse and control focus only by using your keyboard. +The mouse will still be useful inside the currently active window (for example +to click on links in your browser window).

+

Syntax:

+
+
+
focus_follows_mouse <yes|no>
+
+

Examples:

+
+
+
focus_follows_mouse no
+
+
+
+

3.15. Internal workspace bar

+

The internal workspace bar (the thing at the bottom of your screen) is very +simple — it does not provide a way to display custom text and it does not +offer advanced customization features. This is intended because we do not +want to duplicate functionality of tools like dzen2, xmobar and so on +(they render bars, we manage windows). Instead, there is an option which will +turn off the internal bar completely, so that you can use a separate program to +display it (see i3-wsbar, a sample implementation of such a program):

+

Syntax:

+
+
+
workspace_bar <yes|no>
+
+

Examples:

+
+
+
workspace_bar no
+
+
+
+
+
+

4. List of commands

+
+
+

4.1. Manipulating layout

+

To change the layout of the current container to stacking, use s, for default +use d and for tabbed, use T. To make the current client (!) fullscreen, +use f, to make it span all outputs, use fg, to make it floating (or +tiling again) use t:

+

Examples:

+
+
+
bindsym Mod1+s s
+bindsym Mod1+l d
+bindsym Mod1+w T
+
+# Toggle fullscreen
+bindsym Mod1+f f
+
+# Toggle global fullscreen
+bindsym Mod1+Shift+f fg
+
+# Toggle floating/tiling
+bindsym Mod1+t t
+
+
+
+

4.2. Focusing/Moving/Snapping clients/containers/screens

+

To change the focus, use one of the h, j, k and l commands, meaning +left, down, up, right (respectively). To focus a container, prefix it with +wc. To focus a screen, prefix it with ws.

+

The same principle applies for moving and snapping: just prefix the command +with m when moving and with s when snapping:

+

Examples:

+
+
+
# Focus clients on the left, bottom, top, right:
+bindsym Mod1+j h
+bindsym Mod1+k j
+bindsym Mod1+j k
+bindsym Mod1+semicolon l
+
+# Move client to the left, bottom, top, right:
+bindsym Mod1+j mh
+bindsym Mod1+k mj
+bindsym Mod1+j mk
+bindsym Mod1+semicolon ml
+
+# Snap client to the left, bottom, top, right:
+bindsym Mod1+j sh
+bindsym Mod1+k sj
+bindsym Mod1+j sk
+bindsym Mod1+semicolon sl
+
+# Focus container on the left, bottom, top, right:
+bindsym Mod3+j wch
+…
+
+
+
+

4.3. Changing workspaces/moving clients to workspaces

+

To change to a specific workspace, the command is just the number of the +workspace, e.g. 1 or 3. To move the current client to a specific workspace, +prefix the number with an m.

+

You can also switch to the next and previous workspace with the commands nw +and pw, which is handy, for example, if you have workspace 1, 3, 4 and 9 and +you want to cycle through them with a single key combination.

+

Examples:

+
+
+
bindsym Mod1+1 1
+bindsym Mod1+2 2
+...
+
+bindsym Mod1+Shift+1 m1
+bindsym Mod1+Shift+2 m2
+...
+
+bindsym Mod1+o nw
+bindsym Mod1+p pw
+
+
+
+

4.4. Resizing columns/rows

+

If you want to resize columns/rows using your keyboard, you can use the +resize command, I recommend using it inside a so called mode:

+
+
Example: Configuration file, defining a mode for resizing
+
+
mode "resize" {
+        # These bindings trigger as soon as you enter the resize mode
+
+        # They resize the border in the direction you pressed, e.g.
+        # when pressing left, the window is resized so that it has
+        # more space on its left
+
+        bindsym n resize left -10
+        bindsym Shift+n resize left +10
+
+        bindsym r resize bottom +10
+        bindsym Shift+r resize bottom -10
+
+        bindsym t resize top -10
+        bindsym Shift+t resize top +10
+
+        bindsym d resize right +10
+        bindsym Shift+d resize right -10
+
+        bind 36 mode default
+}
+
+# Enter resize mode
+bindsym Mod1+r mode resize
+
+
+
+

4.5. Jumping to specific windows

+

Often when in a multi-monitor environment, you want to quickly jump to a +specific window. For example, while working on workspace 3 you may want to +jump to your mail client to email your boss that you’ve achieved some +important goal. Instead of figuring out how to navigate to your mailclient, +it would be more convenient to have a shortcut.

+

Syntax:

+
+
+
jump ["]window class[/window title]["]
+jump workspace [ column row ]
+
+

You can either use the same matching algorithm as in the assign command +(see above) or you can specify the position of the client if you always use +the same layout.

+

Examples:

+
+
+
# Get me to the next open VIM instance
+bindsym Mod1+a jump "urxvt/VIM"
+
+
+
+

4.6. VIM-like marks (mark/goto)

+

This feature is like the jump feature: It allows you to directly jump to a +specific window (this means switching to the appropriate workspace and setting +focus to the windows). However, you can directly mark a specific window with +an arbitrary label and use it afterwards. You do not need to ensure that your +windows have unique classes or titles, and you do not need to change your +configuration file.

+

As the command needs to include the label with which you want to mark the +window, you cannot simply bind it to a key. i3-input is a tool created +for this purpose: It lets you input a command and sends the command to i3. It +can also prefix this command and display a custom prompt for the input dialog.

+

Syntax:

+
+
+
mark <identifier>
+goto <identifier>
+
+

Examples:

+
+
+
# Read 1 character and mark the current window with this character
+bindsym Mod1+m exec i3-input -p 'mark ' -l 1 -P 'Mark: '
+
+# Read 1 character and go to the window with the character
+bindsym Mod1+g exec i3-input -p 'goto ' -l 1 -P 'Goto: '
+
+

Alternatively, if you do not want to mess with i3-input, you could create +seperate bindings for a specific set of labels and then only use those labels.

+
+
+

4.7. Traveling the focus stack

+

This mechanism can be thought of as the opposite of the jump command. +It travels the focus stack and jumps to the window which had focus previously.

+

Syntax:

+
+
+
focus [number] | floating | tiling | ft
+
+

Where number by default is 1 meaning that the next client in the focus stack +will be selected.

+

The special values have the following meaning:

+
+
+floating +
+
+

+ The next floating window is selected. +

+
+
+tiling +
+
+

+ The next tiling window is selected. +

+
+
+ft +
+
+

+ If the current window is floating, the next tiling window will be + selected; and vice-versa. +

+
+
+
+
+

4.8. Changing border style

+

To change the border of the current client, you can use bn to use the normal +border (including window title), bp to use a 1-pixel border (no window title) +and bb to make the client borderless. There is also bt which will toggle +the different border styles.

+

Examples:

+
+
+
bindsym Mod1+t bn
+bindsym Mod1+y bp
+bindsym Mod1+u bb
+
+
+
+

4.9. Changing the stack-limit of a container

+

If you have a single container with a lot of windows inside it (say, more than +10), the default layout of a stacking container can get a little unhandy. +Depending on your screen’s size, you might end up seeing only half of the +titlebars for each window in the container.

+

Using the stack-limit command, you can limit the number of rows or columns +in a stacking container. i3 will create columns or rows (depending on what +you limited) automatically as needed.

+

Syntax:

+
+
+
stack-limit <cols|rows> <value>
+
+

Examples:

+
+
+
# I always want to have two window titles in one line
+stack-limit cols 2
+
+# Not more than 5 rows in this stacking container
+stack-limit rows 5
+
+

+Container limited to two columns +

+
+
+

4.10. Reloading/Restarting/Exiting

+

You can make i3 reload its configuration file with reload. You can also +restart i3 inplace with the restart command to get it out of some weird state +(if that should ever happen) or to perform an upgrade without having to restart +your X session. However, your layout is not preserved at the moment, meaning +that all open windows will end up in a single container in default layout +after the restart. To exit i3 properly, you can use the exit command, +however you don’t need to (simply killing your X session is fine as well).

+

Examples:

+
+
+
bindsym Mod1+Shift+r restart
+bindsym Mod1+Shift+w reload
+bindsym Mod1+Shift+e exit
+
+
+
+
+
+

5. Multiple monitors

+
+

As you can see in the goal list on the website, i3 was specifically developed +with support for multiple monitors in mind. This section will explain how to +handle multiple monitors.

+

When you have only one monitor, things are simple. You usually start with +workspace 1 on your monitor and open new ones as you need them.

+

When you have more than one monitor, each monitor will get an initial +workspace. The first monitor gets 1, the second gets 2 and a possible third +would get 3. When you switch to a workspace on a different monitor, i3 will +switch to that monitor and then switch to the workspace. This way, you don’t +need shortcuts to switch to a specific monitor, and you don’t need to remember +where you put which workspace. New workspaces will be opened on the currently +active monitor. It is not possible to have a monitor without a workspace.

+

The idea of making workspaces global is based on the observation that most +users have a very limited set of workspaces on their additional monitors. +They are often used for a specific task (browser, shell) or for monitoring +several things (mail, IRC, syslog, …). Thus, using one workspace on one monitor +and "the rest" on the other monitors often makes sense. However, as you can +create an unlimited number of workspaces in i3 and tie them to specific +screens, you can have the "traditional" approach of having X workspaces per +screen by changing your configuration (using modes, for example).

+
+

5.1. Configuring your monitors

+

To help you get going if you have never used multiple monitors before, here is +a short overview of the xrandr options which will probably be of interest to +you. It is always useful to get an overview of the current screen configuration. +Just run "xrandr" and you will get an output like the following:

+
+
+
$ xrandr
+Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192
+VGA1 disconnected (normal left inverted right x axis y axis)
+LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
+   1280x800       60.0*+   50.0
+   1024x768       85.0     75.0     70.1     60.0
+   832x624        74.6
+   800x600        85.1     72.2     75.0     60.3     56.2
+   640x480        85.0     72.8     75.0     59.9
+   720x400        85.0
+   640x400        85.1
+   640x350        85.1
+
+

Several things are important here: You can see that LVDS1 is connected (of +course, it is the internal flat panel) but VGA1 is not. If you have a monitor +connected to one of the ports but xrandr still says "disconnected", you should +check your cable, monitor or graphics driver.

+

The maximum resolution you can see at the end of the first line is the maximum +combined resolution of your monitors. By default, it is usually too low and has +to be increased by editing /etc/X11/xorg.conf.

+

So, say you connected VGA1 and want to use it as an additional screen:

+
+
+
xrandr --output VGA1 --auto --left-of LVDS1
+
+

This command makes xrandr try to find the native resolution of the device +connected to VGA1 and configures it to the left of your internal flat panel. +When running "xrandr" again, the output looks like this:

+
+
+
$ xrandr
+Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 8192 x 8192
+VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
+   1280x1024      60.0*+   75.0
+   1280x960       60.0
+   1152x864       75.0
+   1024x768       75.1     70.1     60.0
+   832x624        74.6
+   800x600        72.2     75.0     60.3     56.2
+   640x480        72.8     75.0     66.7     60.0
+   720x400        70.1
+LVDS1 connected 1280x800+1280+0 (normal left inverted right x axis y axis) 261mm x 163mm
+   1280x800       60.0*+   50.0
+   1024x768       85.0     75.0     70.1     60.0
+   832x624        74.6
+   800x600        85.1     72.2     75.0     60.3     56.2
+   640x480        85.0     72.8     75.0     59.9
+   720x400        85.0
+   640x400        85.1
+   640x350        85.1
+
+

Please note that i3 uses exactly the same API as xrandr does, so it will see +only what you can see in xrandr.

+

See also [presentations] for more examples of multi-monitor setups.

+
+
+

5.2. Interesting configuration for multi-monitor environments

+

There are several things to configure in i3 which may be interesting if you +have more than one monitor:

+
    +
  1. +

    +You can specify which workspace should be put on which screen. This + allows you to have a different set of workspaces when starting than just + 1 for the first monitor, 2 for the second and so on. See + [workspace_screen]. +

    +
    2. +
  2. +

    +If you want some applications to generally open on the bigger screen + (MPlayer, Firefox, …), you can assign them to a specific workspace, see + [assign_workspace]. +

    +
    3. +
  3. +

    +If you have many workspaces on many monitors, it might get hard to keep + track of which window you put where. Thus, you can use vim-like marks to + quickly switch between windows. See [vim_like_marks]. +

    +
    4. +
+
+
+
+
+

6. i3 and the rest of your software world

+
+
+

6.1. Displaying a status line

+

A very common thing amongst users of exotic window managers is a status line at +some corner of the screen. It is an often superior replacement to the widget +approach you have in the task bar of a traditional desktop environment.

+

If you don’t already have your favorite way of generating such a status line +(self-written scripts, conky, …), then i3status is the recommended tool for +this task. It was written in C with the goal of using as few syscalls as +possible to reduce the time your CPU is woken up from sleep states.

+

Regardless of which application you use to generate the status line, you +want to make sure that the application does one of the following things:

+
    +
  1. +

    +Register as a dock window using EWMH hints. This will make i3 position the + window above the workspace bar but below every other client. This is the + recommended way, but in case of dzen2, for example, you need to check out + the source of dzen2 from subversion, as the -dock option is not present + in the released versions. +

    +
    2. +
  2. +

    +Overlay the internal workspace bar. This method will not waste any space + on the workspace bar, however, it is rather hackish. Just configure + the output window to be over the workspace bar (say -x 200 and -y 780 if + your screen is 800 px height). +

    +
    3. +
+

The planned solution for this problem is to make the workspace bar optional +and switch to a third party application completely (dzen2 for example) +which will then contain the workspace bar.

+
+
+

6.2. Giving presentations (multi-monitor)

+

When giving a presentation, you typically want the audience to see what you see +on your screen and then go through a series of slides (if the presentation is +simple). For more complex presentations, you might want to have some notes +which only you can see on your screen, while the audience can only see the +slides.

+
+

6.2.1. Case 1: everybody gets the same output

+

This is the simple case. You connect your computer to the video projector, +turn on both (computer and video projector) and configure your X server to +clone the internal flat panel of your computer to the video output:

+
+
+
xrandr --output VGA1 --mode 1024x768 --same-as LVDS1
+
+

i3 will then use the lowest common subset of screen resolutions, the rest of +your screen will be left untouched (it will show the X background). So, in +our example, this would be 1024x768 (my notebook has 1280x800).

+
+
+

6.2.2. Case 2: you can see more than your audience

+

This case is a bit harder. First of all, you should configure the VGA output +somewhere near your internal flat panel, say right of it:

+
+
+
xrandr --output VGA1 --mode 1024x768 --right-of LVDS1
+
+

Now, i3 will put a new workspace (depending on your settings) on the new screen +and you are in multi-monitor mode (see [multi_monitor]).

+

Because i3 is not a compositing window manager, there is no ability to +display a window on two screens at the same time. Instead, your presentation +software needs to do this job (that is, open a window on each screen).

+
+
+
+
+
+
+ + + diff --git a/docs/3.e/wsbar.html b/docs/3.e/wsbar.html new file mode 100644 index 0000000..7a3b822 --- /dev/null +++ b/docs/3.e/wsbar.html @@ -0,0 +1,147 @@ + + + + + + +i3: External workspace bars + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes why the internal workspace bar is minimal and how an +external workspace bar can be used. It explains the concepts using i3-wsbar +as the reference implementation.

+
+
+
+

1. Internal and external bars

+
+

The internal workspace bar of i3 is meant to be a reasonable default so that +you can use i3 without having too much hassle when setting it up. It is quite +simple and intended to stay this way. So, there is no way to display your own +information in this bar (unlike dwm, wmii, awesome, …).

+

We chose not to implement such a mechanism because that would be duplicating +already existing functionality of tools such as dzen2, xmobar and similar. +Instead, you should disable the internal bar and use an external workspace bar +(which communicates with i3 through its IPC interface).

+
+
+
+

2. dock mode

+
+

You typically want to see the same workspace bar on every workspace on a +specific screen. Also, you don’t want to place the workspace bar somewhere +in your layout by hand. This is where dock mode comes in: When a program sets +the appropriate hint (_NET_WM_WINDOW_TYPE_DOCK), it will be managed in dock +mode by i3. That means it will be placed at the bottom of the screen (while +other edges of the screen are possible in the NetWM standard, this is not yet +implemented in i3), it will not overlap any other window and it will be on +every workspace for the specific screen it was placed on initially.

+
+
+
+

3. The IPC interface

+
+

In the context of using an external workspace bar, the IPC interface needs to +provide the bar program with the current workspaces and output (as in VGA-1, +LVDS-1, …) configuration. In the other direction, the program has to be able +to switch to specific workspaces.

+

By default, the IPC interface is enabled and places its UNIX socket in +~/.i3/ipc.sock.

+

To learn more about the protocol which is used for IPC, see docs/ipc.

+
+
+
+

4. Output changes (on-the-fly)

+
+

i3 implements the RandR API and can handle changing outputs quite well. So, an +external workspace bar implementation needs to make sure that when you change +the resolution of any of your screens (or enable/disable an output), the bars +will be adjusted properly.

+
+
+
+

5. i3-wsbar, the reference implementation

+
+

Please keep in mind that i3-wsbar is just a reference implementation. It is +shipped with i3 to have a reasonable default. Thus, i3-wsbar is designed to +work well with dzen2 and there are no plans to make it more generic.

+
+

5.1. The big picture

+

The most common reason to use an external workspace bar is to integrate system +information such as what i3status provides into the workspace bar (to save +screen space). So, we have i3status or a similar program, which only provides +text output (formatted in some way). To display this text nicely on the screen, +there are programs such as dzen2, xmobar and similar. We will stick to dzen2 +from here on. So, we have the output of i3status, which needs to go into dzen2 +somehow. But we also want to display the list of workspaces. i3-wsbar takes +input on stdin, combines it with a formatted workspace list and pipes it to +dzen2.

+

Please note that i3-wsbar does not print its output to stdout. Instead, it +launches the dzen2 instances on its own. This is necessary to handle changes +in the available outputs (to place a new dzen2 on a new screen for example).

+

+ +Overview + +

+
+
+

5.2. Running i3-wsbar

+

The most simple usage of i3-wsbar looks like this:

+
+
+
i3-wsbar -c "dzen2 -x %x -dock"
+
+

The %x in the command name will be replaced by the X position of the output +for which this workspace bar is running. i3 will automatically place the +workspace bar on the correct output when dzen2 is started in dock mode. The +bar which you will see should look exactly like the internal bar of i3.

+

To actually get a benefit, you want to give i3-wsbar some input:

+
+
+
i3status | i3-wsbar -c "dzen2 -x %x -dock"
+
+

It is recommended to place the above command in your i3 configuration file +to start it automatically with i3.

+
+
+
+
+
+ + + diff --git a/docs/3.e/wsbar.png b/docs/3.e/wsbar.png new file mode 100644 index 0000000..0789dec Binary files /dev/null and b/docs/3.e/wsbar.png differ diff --git a/docs/4.0/bigpicture.png b/docs/4.0/bigpicture.png new file mode 100644 index 0000000..fc3c8db Binary files /dev/null and b/docs/4.0/bigpicture.png differ diff --git a/docs/4.0/debugging.html b/docs/4.0/debugging.html new file mode 100644 index 0000000..4101fc0 --- /dev/null +++ b/docs/4.0/debugging.html @@ -0,0 +1,153 @@ + + + + + + +i3: Debugging i3: How To + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes how to debug i3 suitably for sending us useful bug +reports, even if you have no clue of C programming.

+

First of all: Thank you for being interested in debugging i3. It really means +something to us to get your bug fixed. If you have any questions about the +debugging and/or need further help, do not hesitate to contact us!

+
+
+
+

1. Enabling logging

+
+

i3 logs useful information to stdout. To have a clearly defined place where log +files will be saved, you should redirect stdout and stderr in your +~/.xsession. While you’re at it, putting each run of i3 in a separate log +file with date/time in its filename is a good idea to not get confused about +the different log files later on.

+
+
+
exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1
+
+

To enable verbose output and all levels of debug output (required when +attaching logfiles to bugreports), add the parameters -V -d all, like this:

+
+
+
exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1
+
+
+
+
+

2. Enabling core dumps

+
+

When i3 crashes, often you have the chance of getting a core dump (an image +of the memory of the i3 process which can be loaded into a debugger). To get a +core dump, you have to make sure that the user limit for core dump files is set +high enough. Many systems ship with a default value which even forbids core +dumps completely. To disable the limit completely and thus enable core dumps, +use the following command (in your ~/.xsession, before starting i3):

+
+
+
ulimit -c unlimited
+
+

Furthermore, to easily recognize core dumps and allow multiple of them, you +should set a custom core dump filename pattern, using a command like the +following:

+
+
+
sudo sysctl -w kernel.core_pattern=core.%e.%p
+
+

This will generate files which have the executable’s file name (%e) and the +process id (%p) in it. You can save this setting across reboots using +/etc/sysctl.conf.

+
+
+
+

3. Compiling with debug symbols

+
+

To actually get useful core dumps, you should make sure that your version of i3 +is compiled with debug symbols, that is, that the symbols are not stripped +during the build process. You can check whether your executable contains +symbols by issuing the following command:

+
+
+
file $(which i3)
+
+

You should get an output like this:

+
+
+
/usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
+linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
+
+

Notice the not stripped, which is the important part. If you have a version +which is stripped, please have a look if your distribution provides debug +symbols (package i3-wm-dbg on Debian for example) or if you can turn off +stripping. If nothing helps, please build i3 from source.

+
+
+
+

4. Generating a backtrace

+
+

Once you have made sure that your i3 is compiled with debug symbols and that +core dumps are enabled, you can start making sense out of the core dumps.

+

Because the core dump depends on the original executable (and its debug +symbols), please do this as soon as you encounter the problem. If you +re-compile i3, your core dump might be useless afterwards.

+

Please install gdb, a debugger for C. No worries, you don’t need to learn it +now. Start gdb using the following command (replacing the actual name of the +core dump of course):

+
+
+
gdb $(which i3) core.i3.3849
+
+

Then, generate a backtrace using:

+
+
+
backtrace full
+
+
+
+
+

5. Sending bug reports/debugging on IRC

+
+

When sending bug reports, please paste the relevant part of the log (if in +doubt, please send us rather too much information than too less) and the whole +backtrace (if there was a core dump).

+

When debugging with us in IRC, be prepared to use a so called nopaste service +such as http://nopaste.info or http://pastebin.com because pasting large +amounts of text in IRC sometimes leads to incomplete lines (servers have line +length limitations) or flood kicks.

+
+
+
+
+ + + diff --git a/docs/4.0/hacking-howto.html b/docs/4.0/hacking-howto.html new file mode 100644 index 0000000..382b5c3 --- /dev/null +++ b/docs/4.0/hacking-howto.html @@ -0,0 +1,1046 @@ + + + + + + +i3: Hacking i3: How To + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document is intended to be the first thing you read before looking and/or +touching i3’s source code. It should contain all important information to help +you understand why things are like they are. If it does not mention something +you find necessary, please do not hesitate to contact me.

+
+
+
+

1. Window Managers

+
+

A window manager is not necessarily needed to run X, but it is usually used in +combination with X to facilitate some things. The window manager’s job is to +take care of the placement of windows, to provide the user with some mechanisms +to change the position/size of windows and to communicate with clients to a +certain extent (for example handle fullscreen requests of clients such as +MPlayer).

+

There are no different contexts in which X11 clients run, so a window manager +is just another client, like all other X11 applications. However, it handles +some events which normal clients usually don’t handle.

+

In the case of i3, the tasks (and order of them) are the following:

+
    +
  1. +

    +Grab the key bindings (events will be sent upon keypress/keyrelease) +

    +
    2. +
  2. +

    +Iterate through all existing windows (if the window manager is not started as + the first client of X) and manage them (reparent them, create window + decorations, etc.) +

    +
    3. +
  3. +

    +When new windows are created, manage them +

    +
    4. +
  4. +

    +Handle the client’s _WM_STATE property, but only the _WM_STATE_FULLSCREEN +

    +
    5. +
  5. +

    +Handle the client’s WM_NAME property +

    +
    6. +
  6. +

    +Handle the client’s size hints to display them proportionally +

    +
    7. +
  7. +

    +Handle the client’s urgency hint +

    +
    8. +
  8. +

    +Handle enter notifications (focus follows mouse) +

    +
    9. +
  9. +

    +Handle button (as in mouse buttons) presses for focus/raise on click +

    +
    10. +
  10. +

    +Handle expose events to re-draw own windows such as decorations +

    +
    11. +
  11. +

    +React to the user’s commands: Change focus, Move windows, Switch workspaces, + Change the layout mode of a container (default/stacking/tabbed), start a new + application, restart the window manager +

    +
    12. +
+

In the following chapters, each of these tasks and their implementation details +will be discussed.

+
+

1.1. Tiling window managers

+

Traditionally, there are two approaches to managing windows: The most common +one nowadays is floating, which means the user can freely move/resize the +windows. The other approach is called tiling, which means that your window +manager distributes windows to use as much space as possible while not +overlapping each other.

+

The idea behind tiling is that you should not need to waste your time +moving/resizing windows while you usually want to get some work done. After +all, most users sooner or later tend to lay out their windows in a way which +corresponds to tiling or stacking mode in i3. Therefore, why not let i3 do this +for you? Certainly, it’s faster than you could ever do it.

+

The problem with most tiling window managers is that they are too unflexible. +In my opinion, a window manager is just another tool, and similar to vim which +can edit all kinds of text files (like source code, HTML, …) and is not limited +to a specific file type, a window manager should not limit itself to a certain +layout (like dwm, awesome, …) but provide mechanisms for you to easily create +the layout you need at the moment.

+
+
+

1.2. The layout table

+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+
+
+
+
+

2. Files

+
+
+
+include/atoms.xmacro +
+
+

+A file containing all X11 atoms which i3 uses. This file will be included +various times (for defining, requesting and receiving the atoms), each time +with a different definition of xmacro(). +

+
+
+include/data.h +
+
+

+Contains data definitions used by nearly all files. You really need to read +this first. +

+
+
+include/*.h +
+
+

+Contains forward definitions for all public functions, as well as +doxygen-compatible comments (so if you want to get a bit more of the big +picture, either browse all header files or use doxygen if you prefer that). +

+
+
+src/cfgparse.l +
+
+

+Contains the lexer for i3’s configuration file, written for flex(1). +

+
+
+src/cfgparse.y +
+
+

+Contains the parser for i3’s configuration file, written for bison(1). +

+
+
+src/click.c +
+
+

+Contains all functions which handle mouse button clicks (right mouse button +clicks initiate resizing and thus are relatively complex). +

+
+
+src/cmdparse.l +
+
+

+Contains the lexer for i3 commands, written for flex(1). +

+
+
+src/cmdparse.y +
+
+

+Contains the parser for i3 commands, written for bison(1). +

+
+
+src/con.c +
+
+

+Contains all functions which deal with containers directly (creating +containers, searching containers, getting specific properties from containers, +…). +

+
+
+src/config.c +
+
+

+Contains all functions handling the configuration file (calling the parser +(src/cfgparse.y) with the correct path, switching key bindings mode). +

+
+
+src/debug.c +
+
+

+Contains debugging functions to print unhandled X events. +

+
+
+src/ewmh.c +
+
+

+iFunctions to get/set certain EWMH properties easily. +

+
+
+src/floating.c +
+
+

+Contains functions for floating mode (mostly resizing/dragging). +

+
+
+src/handlers.c +
+
+

+Contains all handlers for all kinds of X events (new window title, new hints, +unmapping, key presses, button presses, …). +

+
+
+src/ipc.c +
+
+

+Contains code for the IPC interface. +

+
+
+src/load_layout.c +
+
+

+Contains code for loading layouts from JSON files. +

+
+
+src/log.c +
+
+

+Handles the setting of loglevels, contains the logging functions. +

+
+
+src/main.c +
+
+

+Initializes the window manager. +

+
+
+src/manage.c +
+
+

+Looks at existing or new windows and decides whether to manage them. If so, it +reparents the window and inserts it into our data structures. +

+
+
+src/match.c +
+
+

+A "match" is a data structure which acts like a mask or expression to match +certain windows or not. For example, when using commands, you can specify a +command like this: [title="Firefox"] kill. The title member of the match +data structure will then be filled and i3 will check each window using +match_matches_window() to find the windows affected by this command. +

+
+
+src/move.c +
+
+

+Contains code to move a container in a specific direction. +

+
+
+src/output.c +
+
+

+Functions to handle CT_OUTPUT cons. +

+
+
+src/randr.c +
+
+

+The RandR API is used to get (and re-query) the configured outputs (monitors, +…). +

+
+
+src/render.c +
+
+

+Renders the tree data structure by assigning coordinates to every node. These +values will later be pushed to X11 in src/x.c. +

+
+
+src/resize.c +
+
+

+Contains the functions to resize containers. +

+
+
+src/sighandler.c +
+
+

+Handles SIGSEGV, SIGABRT and SIGFPE by showing a dialog that i3 crashed. +You can chose to let it dump core, to restart it in-place or to restart it +in-place but forget about the layout. +

+
+
+src/tree.c +
+
+

+Contains functions which open or close containers in the tree, change focus or +cleanup ("flatten") the tree. See also src/move.c for another similar +function, which was moved into its own file because it is so long. +

+
+
+src/util.c +
+
+

+Contains useful functions which are not really dependant on anything. +

+
+
+src/window.c +
+
+

+Handlers to update X11 window properties like WM_CLASS, _NET_WM_NAME, +CLIENT_LEADER, etc. +

+
+
+src/workspace.c +
+
+

+Contains all functions related to workspaces (displaying, hiding, renaming…) +

+
+
+src/x.c +
+
+

+Transfers our in-memory tree (see src/render.c) to X11. +

+
+
+src/xcb.c +
+
+

+Contains wrappers to use xcb more easily. +

+
+
+src/xcursor.c +
+
+

+XCursor functions (for cursor themes). +

+
+
+src/xinerama.c +
+
+

+Legacy support for Xinerama. See src/randr.c for the preferred API. +

+
+
+
+
+
+

3. Data structures

+
+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+

So, the hierarchy is:

+
    +
  1. +

    +X11 root window, the root container +

    +
    2. +
  2. +

    +Virtual screens (Screen 0 in this example) +

    +
    3. +
  3. +

    +Content container (there are also containers for dock windows) +

    +
    4. +
  4. +

    +Workspaces (Workspace 1 in this example, with horizontal orientation) +

    +
    5. +
  5. +

    +Split container (vertically split) +

    +
    6. +
  6. +

    +X11 window containers +

    +
    7. +
+

The data type is Con, in all cases.

+
+

3.1. Virtual screens

+

A virtual screen (type i3Screen) is generated from the connected outputs +obtained through RandR. The difference to the raw RandR outputs as seen +when using xrandr(1) is that it falls back to the lowest common resolution of +the actual enabled outputs.

+

For example, if your notebook has a screen resolution of 1280x800 px and you +connect a video projector with a resolution of 1024x768 px, set it up in clone +mode (xrandr --output VGA1 --mode 1024x768 --same-as LVDS1), i3 will have +one virtual screen.

+

However, if you configure it using xrandr --output VGA1 --mode 1024x768 +--right-of LVDS1, i3 will generate two virtual screens. For each virtual +screen, a new workspace will be assigned. New workspaces are created on the +screen you are currently on.

+
+
+

3.2. Workspace

+

A workspace is identified by its name. Basically, you could think of +workspaces as different desks in your office, if you like the desktop +methaphor. They just contain different sets of windows and are completely +separate of each other. Other window managers also call this “Virtual +desktops”.

+
+
+

3.3. The layout table

+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+
+
+

3.4. Container

+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+
+
+

3.5. Client

+

A client is x11-speak for a window.

+
+
+
+
+

4. List/queue macros

+
+

i3 makes heavy use of the list macros defined in BSD operating systems. To +ensure that the operating system on which i3 is compiled has all the expected +features, i3 comes with include/queue.h. On BSD systems, you can use man +queue(3). On Linux, you have to use google (or read the source).

+

The lists used are SLIST (single linked lists), CIRCLEQ (circular +queues) and TAILQ (tail queues). Usually, only forward traversal is necessary, +so an SLIST works fine. If inserting elements at arbitrary positions or at +the end of a list is necessary, a TAILQ is used instead. However, for the +windows inside a container, a CIRCLEQ is necessary to go from the currently +selected window to the window above/below.

+
+
+
+

5. Naming conventions

+
+

There is a row of standard variables used in many events. The following names +should be chosen for those:

+
    +
  • +

    +“conn” is the xcb_connection_t +

    +
    • +
  • +

    +“event” is the event of the particular type +

    +
    • +
  • +

    +“con” names a container +

    +
    • +
  • +

    +“current” is a loop variable when using TAILQ_FOREACH etc. +

    +
    • +
+
+
+
+

6. Startup (src/mainx.c, main())

+
+
    +
  • +

    +Establish the xcb connection +

    +
    • +
  • +

    +Check for XKB extension on the separate X connection, load Xcursor +

    +
    • +
  • +

    +Check for RandR screens (with a fall-back to Xinerama) +

    +
    • +
  • +

    +Grab the keycodes for which bindings exist +

    +
    • +
  • +

    +Manage all existing windows +

    +
    • +
  • +

    +Enter the event loop +

    +
    • +
+
+
+
+

7. Keybindings

+
+
+

7.1. Grabbing the bindings

+

Grabbing the bindings is quite straight-forward. You pass X your combination of +modifiers and the keycode you want to grab and whether you want to grab them +actively or passively. Most bindings (everything except for bindings using +Mode_switch) are grabbed passively, that is, just the window manager gets the +event and cannot replay it.

+

We need to grab bindings that use Mode_switch actively because of a bug in X. +When the window manager receives the keypress/keyrelease event for an actively +grabbed keycode, it has to decide what to do with this event: It can either +replay it so that other applications get it or it can prevent other +applications from receiving it.

+

So, why do we need to grab keycodes actively? Because X does not set the +state-property of keypress/keyrelease events properly. The Mode_switch bit is +not set and we need to get it using XkbGetState. This means we cannot pass X +our combination of modifiers containing Mode_switch when grabbing the key and +therefore need to grab the keycode itself without any modifiers. This means, +if you bind Mode_switch + keycode 38 ("a"), i3 will grab keycode 38 ("a") and +check on each press of "a" if the Mode_switch bit is set using XKB. If yes, it +will handle the event, if not, it will replay the event.

+
+
+

7.2. Handling a keypress

+

As mentioned in "Grabbing the bindings", upon a keypress event, i3 first gets +the correct state.

+

Then, it looks through all bindings and gets the one which matches the received +event.

+

The bound command is parsed by the cmdparse lexer/parser, see parse_cmd in +src/cmdparse.y.

+
+
+
+
+

8. Manage windows (src/main.c, manage_window() and reparent_window())

+
+

manage_window() does some checks to decide whether the window should be +managed at all:

+
    +
  • +

    +Windows have to be mapped, that is, visible on screen +

    +
    • +
  • +

    +The override_redirect must not be set. Windows with override_redirect shall + not be managed by a window manager +

    +
    • +
+

Afterwards, i3 gets the intial geometry and reparents the window (see +reparent_window()) if it wasn’t already managed.

+

Reparenting means that for each window which is reparented, a new window, +slightly larger than the original one, is created. The original window is then +reparented to the bigger one (called "frame").

+

After reparenting, the window type (_NET_WM_WINDOW_TYPE) is checked to see +whether this window is a dock (_NET_WM_WINDOW_TYPE_DOCK), like dzen2 for +example. Docks are handled differently, they don’t have decorations and are not +assigned to a specific container. Instead, they are positioned at the bottom +of the screen. To get the height which needs to be reserved for the window, +the _NET_WM_STRUT_PARTIAL property is used.

+

Furthermore, the list of assignments (to other workspaces, which may be on +other screens) is checked. If the window matches one of the user’s criteria, +it may either be put in floating mode or moved to a different workspace. If the +target workspace is not visible, the window will not be mapped.

+
+
+
+

9. What happens when an application is started?

+
+

i3 does not care for applications. All it notices is when new windows are +mapped (see src/handlers.c, handle_map_request()). The window is then +reparented (see section "Manage windows").

+

After reparenting the window, render_tree() is called which renders the +internal layout table. The new window has been placed in the currently focused +container and therefore the new window and the old windows (if any) need to be +moved/resized so that the currently active layout (default/stacking/tabbed mode) +is rendered correctly. To move/resize windows, a window is “configured” in +X11-speak.

+

Some applications, such as MPlayer obviously assume the window manager is +stupid and try to configure their windows by themselves. This generates an +event called configurerequest. i3 handles these events and tells the window the +size it had before the configurerequest (with the exception of not yet mapped +windows, which get configured like they want to, and floating windows, which +can reconfigure themselves).

+
+
+
+

10. _NET_WM_STATE

+
+

Only the _NET_WM_STATE_FULLSCREEN atom is handled. It calls +“toggle_fullscreen()” for the specific client which just configures the +client to use the whole screen on which it currently is. Also, it is set as +fullscreen_client for the i3Screen.

+
+
+
+

11. WM_NAME

+
+

When the WM_NAME property of a window changes, its decoration (containing the +title) is re-rendered. Note that WM_NAME is in COMPOUND_TEXT encoding which is +totally uncommon and cumbersome. Therefore, the _NET_WM_NAME atom will be used +if present.

+
+
+
+

12. _NET_WM_NAME

+
+

Like WM_NAME, this atom contains the title of a window. However, _NET_WM_NAME +is encoded in UTF-8. i3 will recode it to UCS-2 in order to be able to pass it +to X. Using an appropriate font (ISO-10646), you can see most special +characters (every special character contained in your font).

+
+
+
+

13. Size hints

+
+

Size hints specify the minimum/maximum size for a given window as well as its +aspect ratio. This is important for clients like mplayer, who only set the +aspect ratio and resize their window to be as small as possible (but only with +some video outputs, for example in Xv, while when using x11, mplayer does the +necessary centering for itself).

+

So, when an aspect ratio was specified, i3 adjusts the height of the window +until the size maintains the correct aspect ratio. For the code to do this, see +src/layout.c, function resize_client().

+
+
+
+

14. Rendering (src/layout.c, render_layout() and render_container())

+
+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+
+
+
+

15. User commands / commandmode (src/cmdparse.{l,y})

+
+
+
+

This section has not been updated for v4.0 yet, sorry! We wanted to release on +time, but we will update this soon. Please talk to us on IRC if you need to +know stuff NOW :).

+
+
+
+
+

16. Moving containers

+
+

The movement code is pretty delicate. You need to consider all cases before +making any changes or before being able to fully understand how it works.

+
+

16.1. Case 1: Moving inside the same container

+

The reference layout for this case is a single workspace in horizontal +orientation with two containers on it. Focus is on the left container (1).

+
+ +++ + + + + + +

1

2

+
+

When moving the left window to the right (command move right), tree_move will +look for a container with horizontal orientation and finds the parent of the +left container, that is, the workspace. Afterwards, it runs the code branch +commented with "the easy case": it calls TAILQ_NEXT to get the container right +of the current one and swaps both containers.

+
+
+

16.2. Case 2: Move a container into a split container

+

The reference layout for this case is a horizontal workspace with two +containers. The right container is a v-split with two containers. Focus is on +the left container (1).

+
+ +++ + + + + + + + + +

1

2

3

+
+

When moving to the right (command move right), i3 will work like in case 1 +("the easy case"). However, as the right container is not a leaf container, but +a v-split, the left container (1) will be inserted at the right position (below +2, assuming that 2 is focused inside the v-split) by calling insert_con_into.

+

insert_con_into detaches the container from its parent and inserts it +before/after the given target container. Afterwards, the on_remove_child +callback is called on the old parent container which will then be closed, if +empty.

+

Afterwards, con_focus will be called to fix the focus stack and the tree will +be flattened.

+
+
+

16.3. Case 3: Moving to non-existant top/bottom

+

Like in case 1, the reference layout for this case is a single workspace in +horizontal orientation with two containers on it. Focus is on the left +container:

+
+ +++ + + + + + +

1

2

+
+

This time however, the command is move up or move down. tree_move will look +for a container with vertical orientation. As it will not find any, +same_orientation is NULL and therefore i3 will perform a forced orientation +change on the workspace by creating a new h-split container, moving the +workspace contents into it and then changing the workspace orientation to +vertical. Now it will again search for parent containers with vertical +orientation and it will find the workspace.

+

This time, the easy case code path will not be run as we are not moving inside +the same container. Instead, insert_con_into will be called with the focused +container and the container above/below the current one (on the level of +same_orientation).

+

Now, con_focus will be called to fix the focus stack and the tree will be +flattened.

+
+
+

16.4. Case 4: Moving to existant top/bottom

+

The reference layout for this case is a vertical workspace with two containers. +The bottom one is a h-split containing two containers (1 and 2). Focus is on +the bottom left container (1).

+
+ +++ + + + + + + + + +

3

1

2

+
+

This case is very much like case 3, only this time the forced workspace +orientation change does not need to be performed because the workspace already +is in vertical orientation.

+
+
+

16.5. Case 5: Moving in one-child h-split

+

The reference layout for this case is a horizontal workspace with two +containers having a v-split on the left side with a one-child h-split on the +bottom. Focus is on the bottom left container (2(h)):

+
+ +++ + + + + + + + + +

1

3

2(h)

+
+

In this case, same_orientation will be set to the h-split container around +the focused container. However, when trying the easy case, the next/previous +container swap will be NULL. Therefore, i3 will search again for a +same_orientation container, this time starting from the parent of the h-split +container.

+

After determining a new same_orientation container (if it is NULL, the +orientation will be force-changed), this case is equivalent to case 2 or case +4.

+
+
+

16.6. Case 6: Floating containers

+

The reference layout for this case is a horizontal workspace with two +containers plus one floating h-split container. Focus is on the floating +container.

+

TODO: nice illustration. table not possible?

+

When moving up/down, the container needs to leave the floating container and it +needs to be placed on the workspace (at workspace level). This is accomplished +by calling the function attach_to_workspace.

+
+
+
+
+

17. Click handling

+
+

Without much ado, here is the list of cases which need to be considered:

+
    +
  • +

    +click to focus (tiling + floating) and raise (floating) +

    +
    • +
  • +

    +click to focus/raise when in stacked/tabbed mode +

    +
    • +
  • +

    +floating_modifier + left mouse button to drag a floating con +

    +
    • +
  • +

    +floating_modifier + right mouse button to resize a floating con +

    +
    • +
  • +

    +click on decoration in a floating con to either initiate a resize (if there + is more than one child in the floating con) or to drag the + floating con (if it’s the one at the top). +

    +
    • +
  • +

    +click on border in a floating con to resize the floating con +

    +
    • +
  • +

    +floating_modifier + right mouse button to resize a tiling con +

    +
    • +
  • +

    +click on border/decoration to resize a tiling con +

    +
    • +
+
+
+
+

18. Gotchas

+
+
    +
  • +

    +Forgetting to call xcb_flush(conn); after sending a request. This usually + leads to code which looks like it works fine but which does not work under + certain conditions. +

    +
    • +
+
+
+
+

19. Using git / sending patches

+
+

For a short introduction into using git, see +http://www.spheredev.org/wiki/Git_for_the_lazy or, for more documentation, see +http://git-scm.com/documentation

+

When you want to send a patch because you fixed a bug or implemented a cool +feature (please talk to us before working on features to see whether they are +maybe already implemented, not possible for some some reason, or don’t fit +into the concept), please use git to create a patchfile.

+

First of all, update your working copy to the latest version of the master +branch:

+
+
+
git pull
+
+

Afterwards, make the necessary changes for your bugfix/feature. Then, review +the changes using git diff (you might want to enable colors in the diff using +git config diff.color auto). When you are definitely done, use git commit +-a to commit all changes you’ve made.

+

Then, use the following command to generate a patchfile which we can directly +apply to the branch, preserving your commit message and name:

+
+
+
git format-patch origin
+
+

Just send us the generated file via email.

+
+
+
+
+ + + diff --git a/docs/4.0/i3-config-wizard.html b/docs/4.0/i3-config-wizard.html new file mode 100644 index 0000000..1389d2f --- /dev/null +++ b/docs/4.0/i3-config-wizard.html @@ -0,0 +1,96 @@ + + + + + + +i3: i3-config-wizard(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3-config-wizard - creates a keysym based config based on your layout

+
+
+
+

2. SYNOPSIS

+
+

i3-config-wizard

+
+
+
+

3. FILES

+
+
+

3.1. /etc/i3/config.keycodes

+

This file contains the default configuration with keycodes. All the bindcode +lines will be transformed to bindsym and the user-specified modifier will be +used.

+
+
+
+
+

4. DESCRIPTION

+
+

i3-config-wizard is started by i3 in its default config, unless /.i3/config +exists. i3-config-wizard creates a keysym based i3 config file (based on +/etc/i3/config.keycodes) in /.i3/config.

+

The advantage of using keysyms is that the config file is easy to read, +understand and modify. However, if we shipped with a keysym based default +config file, the key positions would not be consistent across different +keyboard layouts (take for example the homerow for movement). Therefore, we +ship with a keycode based default config and let the wizard transform it +according to your current keyboard layout.

+
+
+
+

5. SEE ALSO

+
+

i3(1)

+
+
+
+

6. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/4.0/i3-migrate-config-to-v4.html b/docs/4.0/i3-migrate-config-to-v4.html new file mode 100644 index 0000000..e2c31b2 --- /dev/null +++ b/docs/4.0/i3-migrate-config-to-v4.html @@ -0,0 +1,87 @@ + + + + + + +i3: i3-migrate-config-to-v4(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3-migrate-config-to-v4 - migrates your i3 config file

+
+
+
+

2. SYNOPSIS

+
+
+
+
mv ~/.i3/config ~/.i3/old.config
+i3-migrate-config-to-v4 ~/.i3/old.config > ~/.i3/config
+
+
+
+
+

3. DESCRIPTION

+
+

i3-migrate-config-to-v4 is a Perl script which migrates your old (< version 4) +configuration files to a version 4 config file. The most significant changes +are the new commands (see the release notes).

+

This script will automatically be run by i3 when it detects an old config file. +Please migrate your config file as soon as possible. We plan to include this +script in all i3 release until 2012-08-01. Afterwards, old config files will no +longer be supported.

+
+
+
+

4. SEE ALSO

+
+

i3(1)

+
+
+
+

5. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/4.0/i3-msg.html b/docs/4.0/i3-msg.html new file mode 100644 index 0000000..2324fab --- /dev/null +++ b/docs/4.0/i3-msg.html @@ -0,0 +1,100 @@ + + + + + + +i3: i3-msg(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3-msg - send messages to i3 window manager

+
+
+
+

2. SYNOPSIS

+
+

i3-msg "message"

+
+
+
+

3. DESCRIPTION

+
+

i3-msg is a sample implementation for a client using the unix socket IPC +interface to i3. At the moment, it can only be used for sending commands +(like in configuration file for key bindings), but this may change in the +future (staying backwards-compatible, of course).

+
+
+
+

4. EXAMPLE

+
+
+
+
i3-msg "bp" # Use 1-px border for current client
+
+
+
+
+

5. ENVIRONMENT

+
+
+

5.1. I3SOCK

+

If no ipc-socket is specified on the commandline, this variable is used +to determine the path, at wich the unix domain socket is expected, on which +to connect to i3.

+
+
+
+
+

6. SEE ALSO

+
+

i3(1)

+
+
+
+

7. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/4.0/i3-nagbar.html b/docs/4.0/i3-nagbar.html new file mode 100644 index 0000000..64ee27e --- /dev/null +++ b/docs/4.0/i3-nagbar.html @@ -0,0 +1,90 @@ + + + + + + +i3: i3-nagbar(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3-nagbar - displays an error bar on top of your screen

+
+
+
+

2. SYNOPSIS

+
+

i3-nagbar -m message -b label action

+
+
+
+

3. DESCRIPTION

+
+

i3-nagbar is used by i3 to tell you about errors in your configuration file +(for example). While these errors are logged to the logfile (if any), the past +has proven that users are either not aware of their logfile or do not check it +after modifying the configuration file.

+
+
+
+

4. EXAMPLE

+
+
+
+
i3-nagbar -m 'You have an error in your i3 config file!' \
+-b 'edit config' 'xterm $EDITOR ~/.i3/config'
+
+
+
+
+

5. SEE ALSO

+
+

i3(1)

+
+
+
+

6. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/4.0/i3.html b/docs/4.0/i3.html new file mode 100644 index 0000000..1edda79 --- /dev/null +++ b/docs/4.0/i3.html @@ -0,0 +1,527 @@ + + + + + + +i3: i3(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3 - an improved dynamic, tiling window manager

+
+
+
+

2. SYNOPSIS

+
+

i3 [-a] [-c configfile] [-C] [-d <loglevel>] [-v] [-V]

+
+
+
+

3. OPTIONS

+
+
+
+-a +
+
+

+Disables autostart. +

+
+
+-c +
+
+

+Specifies an alternate configuration file path. +

+
+
+-C +
+
+

+Check the configuration file for validity and exit. +

+
+
+-d +
+
+

+Specifies the debug loglevel. To see the most output, use -d all. +

+
+
+-v +
+
+

+Display version number (and date of the last commit). +

+
+
+-V +
+
+

+Be verbose. +

+
+
+
+
+
+

4. DESCRIPTION

+
+
+

4.1. INTRODUCTION

+

i3 was created because wmii, our favorite window manager at the time, didn’t +provide some features we wanted (multi-monitor done right, for example), had +some bugs, didn’t progress since quite some time and wasn’t easy to hack at all +(source code comments/documentation completely lacking). Still, we think the +wmii developers and contributors did a great job. Thank you for inspiring us to +create i3.

+

Please be aware that i3 is primarily targeted at advanced users and developers.

+
+
+

4.2. IMPORTANT NOTE TO nVidia BINARY DRIVER USERS

+

If you are using the nVidia binary graphics driver (also known as blob) +you need to use the --force-xinerama flag (in your ~/.xsession) when starting +i3, like so:

+
+
+
exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
+
+

See also docs/multi-monitor for the full explanation.

+
+
+

4.3. TERMINOLOGY

+
+
+Tree +
+
+

+i3 keeps your layout in a tree data structure. +

+
+
+Window +
+
+

+An X11 window, like the Firefox browser window or a terminal emulator. +

+
+
+Split container +
+
+

+A split container contains multiple other split containers or windows. +

+

Containers can be used in various layouts. The default mode is called "default" +and just resizes each client equally so that it fits.

+
+
+Workspace +
+
+

+A workspace is a set of containers. Other window managers call this "Virtual +Desktops". +

+

In i3, each workspace is assigned to a specific virtual screen. By default, +screen 1 has workspace 1, screen 2 has workspace 2 and so on… However, when you +create a new workspace (by simply switching to it), it’ll be assigned the +screen you are currently on.

+
+
+Output +
+
+

+Using XRandR, you can have an X11 screen spanning multiple real monitors. +Furthermore, you can set them up in cloning mode or with positions (monitor 1 +is left of monitor 2). +

+

i3 uses the RandR API to query which outputs are available and which screens +are connected to these outputs.

+
+
+
+
+
+
+

5. KEYBINDINGS

+
+

Here is a short overview of the default keybindings:

+
+
+j/k/l/; +
+
+

+Direction keys (left, down, up, right). They are on your homerow (see the mark +on your "j" key). Alternatively, you can use the cursor keys. +

+
+
+Mod1+<direction> +
+
+

+Focus window in <direction>. +

+
+
+Mod1+Shift+<direction> +
+
+

+Move window to <direction>. +

+
+
+Mod1+<number> +
+
+

+Switch to workspace <number>. +

+
+
+Mod1+Shift+<number> +
+
+

+Move window to workspace <number>. +

+
+
+Mod1+f +
+
+

+Toggle fullscreen mode. +

+
+
+Mod1+s +
+
+

+Enable stacking layout for the current container. +

+
+
+Mod1+e +
+
+

+Enable default layout for the current container. +

+
+
+Mod1+w +
+
+

+Enable tabbed layout for the current container. +

+
+
+Mod1+Shift+Space +
+
+

+Toggle tiling/floating for the current container. +

+
+
+Mod1+Space +
+
+

+Select the first tiling container if the current container is floating and +vice-versa. +

+
+
+Mod1+Shift+q +
+
+

+Kills the current window. This is equivalent to "clicking on the close button", +meaning a polite request to the application to close this window. For example, +Firefox will save its session upon such a request. If the application does not +support that, the window will be killed and it depends on the application what +happens. +

+
+
+Mod1+Shift+r +
+
+

+Restarts i3 in place. Your layout will be preserved. +

+
+
+Mod1+Shift+e +
+
+

+Exits i3. +

+
+
+
+
+
+

6. FILES

+
+
+

6.1. ~/.i3/config (or ~/.config/i3/config)

+

When starting, i3 looks for configuration files in the following order:

+
    +
  1. +

    +~/.config/i3/config (or $XDG_CONFIG_HOME/i3/config if set) +

    +
    2. +
  2. +

    +/etc/xdg/i3/config (or $XDG_CONFIG_DIRS/i3/config if set) +

    +
    3. +
  3. +

    +~/.i3/config +

    +
    4. +
  4. +

    +/etc/i3/config +

    +
    5. +
+

You can specify a custom path using the -c option.

+
+
Sample configuration
+
+
# i3 config file (v4)
+
+# font for window titles. ISO 10646 = Unicode
+font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+
+# use Mouse+Mod1 to drag floating windows to their wanted position
+floating_modifier Mod1
+
+# start a terminal
+bindsym Mod1+Return exec /usr/bin/urxvt
+
+# kill focused window
+bindsym Mod1+Shift+q kill
+
+# start dmenu (a program launcher)
+bindsym Mod1+d exec /usr/bin/dmenu_run
+
+# change focus
+bindsym Mod1+j focus left
+bindsym Mod1+k focus down
+bindsym Mod1+l focus up
+bindsym Mod1+semicolon focus right
+
+# alternatively, you can use the cursor keys:
+bindsym Mod1+Left focus left
+bindsym Mod1+Down focus down
+bindsym Mod1+Up focus up
+bindsym Mod1+Right focus right
+
+# move focused window
+bindsym Mod1+Shift+j move left
+bindsym Mod1+Shift+k move down
+bindsym Mod1+Shift+l move up
+bindsym Mod1+Shift+semicolon move right
+
+# alternatively, you can use the cursor keys:
+bindsym Mod1+Shift+Left move left
+bindsym Mod1+Shift+Down move down
+bindsym Mod1+Shift+Up move up
+bindsym Mod1+Shift+Right move right
+
+# split in horizontal orientation
+bindsym Mod1+h split h
+
+# split in vertical orientation
+bindsym Mod1+v split v
+
+# enter fullscreen mode for the focused container
+bindsym Mod1+f fullscreen
+
+# change container layout (stacked, tabbed, default)
+bindsym Mod1+s layout stacking
+bindsym Mod1+w layout tabbed
+bindsym Mod1+e layout default
+
+# toggle tiling / floating
+bindsym Mod1+Shift+space floating toggle
+
+# change focus between tiling / floating windows
+bindsym Mod1+space focus mode_toggle
+
+# focus the parent container
+bindsym Mod1+a focus parent
+
+# focus the child container
+#bindsym Mod1+d focus child
+
+# switch to workspace
+bindsym Mod1+1 workspace 1
+bindsym Mod1+2 workspace 2
+# ..
+
+# move focused container to workspace
+bindsym Mod1+Shift+1 move workspace 1
+bindsym Mod1+Shift+2 move workspace 2
+# ...
+
+# reload the configuration file
+bindsym Mod1+Shift+c reload
+# restart i3 inplace (preserves your layout/session, can be used to upgrade i3)
+bindsym Mod1+Shift+r restart
+# exit i3 (logs you out of your X session)
+bindsym Mod1+Shift+e exit
+
+# Start i3bar to display a workspace bar (plus the system information i3status
+# finds out, if available)
+exec i3status | i3bar -d
+
+
+
+

6.2. ~/.xsession

+

This file is where you should configure your locales and start i3. It is run by +your login manager (xdm, slim, gdm, …) as soon as you login.

+
+
Sample xsession
+
+
# Disable DPMS turning off the screen
+xset -dpms
+xset s off
+
+# Disable bell
+xset -b
+
+# Enable zapping (C-A-<Bksp> kills X)
+setxkbmap -option terminate:ctrl_alt_bksp
+
+# Enforce correct locales from the beginning
+unset LC_COLLATE
+export LC_CTYPE=de_DE.UTF-8
+export LC_TIME=de_DE.UTF-8
+export LC_NUMERIC=de_DE.UTF-8
+export LC_MONETARY=de_DE.UTF-8
+export LC_MESSAGES=C
+export LC_PAPER=de_DE.UTF-8
+export LC_NAME=de_DE.UTF-8
+export LC_ADDRESS=de_DE.UTF-8
+export LC_TELEPHONE=de_DE.UTF-8
+export LC_MEASUREMENT=de_DE.UTF-8
+export LC_IDENTIFICATION=de_DE.UTF-8
+
+# Use XToolkit in java applications
+export AWT_TOOLKIT=XToolkit
+
+# Set background color
+xsetroot -solid "#333333"
+
+# Enable core dumps in case something goes wrong
+ulimit -c unlimited
+
+# Start i3 and log to ~/.i3/logfile
+echo "Starting at $(date)" >> ~/.i3/logfile
+exec /usr/bin/i3 -V -d all >> ~/.i3/logfile
+
+
+
+
+
+

7. ENVIRONMENT

+
+
+

7.1. I3SOCK

+

This variable overwrites the IPC socket path (placed in +/tmp/i3-%u/ipc-socket.%p by default, where %u is replaced with your UNIX +username and %p is replaced with i3’s PID). The IPC socket is used by external +programs like i3-msg(1) or i3bar(1).

+
+
+
+
+

8. TODO

+
+

There is still lot of work to do. Please check our bugtracker for up-to-date +information about tasks which are still not finished.

+
+
+
+

9. SEE ALSO

+
+

You should have a copy of the userguide (featuring nice screenshots/graphics +which is why this is not integrated into this manpage), the debugging guide, +and the "how to hack" guide. If you are building from source, run: + make -C docs

+

You can also access these documents online at http://i3.zekjur.net/

+

i3-input(1), i3-msg(1), i3-wsbar(1), i3-nagbar(1), i3-config-wizard(1), +i3-migrate-config-to-v4(1)

+
+
+
+

10. AUTHOR

+
+

Michael Stapelberg and contributors

+
+
+
+
+ + + diff --git a/docs/4.0/i3status.html b/docs/4.0/i3status.html new file mode 100644 index 0000000..0860168 --- /dev/null +++ b/docs/4.0/i3status.html @@ -0,0 +1,372 @@ + + + + + + +i3: i3status(1) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. NAME

+
+

i3status - Generates a status line for dzen2 or xmobar

+
+
+
+

2. SYNOPSIS

+
+

i3status [-c configfile] [-h] [-v]

+
+
+
+

3. OPTIONS

+
+
+
+-c +
+
+

+Specifies an alternate configuration file path. By default, i3status looks for +configuration files in the following order: +

+
    +
  1. +

    +~/.i3status.conf +

    +
    2. +
  2. +

    +~/.config/i3status/config (or $XDG_CONFIG_HOME/i3status/config if set) +

    +
    3. +
  3. +

    +/etc/i3status.conf +

    +
    4. +
  4. +

    +/etc/xdg/i3status/config (or $XDG_CONFIG_DIRS/i3status/config if set) +

    +
    5. +
+
+
+
+
+
+

4. DESCRIPTION

+
+

i3status is a small program (about 1500 SLOC) for generating a status bar for +i3bar, dzen2, xmobar or similar programs. It is designed to be very +efficient by issuing a very small number of system calls, as one generally +wants to update such a status line every second. This ensures that even under +high load, your status bar is updated correctly. Also, it saves a bit of energy +by not hogging your CPU as much as spawning the corresponding amount of shell +commands would.

+
+
+
+

5. CONFIGURATION

+
+

Since version 2, the configuration file for i3status will be parsed using +libconfuse. This makes configuration easier in the programmer’s point of +view and more flexible for the user at the same time.

+

The basic idea of i3status is that you can specify which "modules" should +be used (the order directive). You can then configure each module with its +own section. For every module, you can specify the output format. See below +for a complete reference.

+
+
Sample configuration
+
+
general {
+        output_format = "dzen2"
+        colors = true
+        interval = 5
+}
+
+order  = "ipv6"
+order += "disk /"
+order += "run_watch DHCP"
+order += "run_watch VPN"
+order += "wireless wlan0"
+order += "ethernet eth0"
+order += "battery 0"
+order += "cpu_temperature 0"
+order += "load"
+order += "time"
+
+wireless wlan0 {
+        format_up = "W: (%quality at %essid, %bitrate) %ip"
+        format_down = "W: down"
+}
+
+ethernet eth0 {
+        # if you use %speed, i3status requires the cap_net_admin capability
+        format_up = "E: %ip (%speed)"
+        format_down = "E: down"
+}
+
+battery 0 {
+        format = "%status %percentage %remaining"
+}
+
+run_watch DHCP {
+        pidfile = "/var/run/dhclient*.pid"
+}
+
+run_watch VPN {
+        pidfile = "/var/run/vpnc/pid"
+}
+
+time {
+        format = "%Y-%m-%d %H:%M:%S"
+}
+
+load {
+        format = "%5min"
+}
+
+cpu_temperature 0 {
+        format = "T: %degrees °C"
+        path = "/sys/devices/platform/coretemp.0/temp1_input"
+}
+
+disk "/" {
+        format = "%free"
+}
+
+
+

5.1. General

+

The colors directive will disable all colors if you set it to false. You can +also specify the colors that will be used to display "good", "degraded" or "bad" +values using the color_good, color_degraded or color_bad directives, +respectively. Those directives are only used if color support is not disabled by +the colors directive. The input format for color values is the canonical RGB +hexadecimal triplet (with no separators between the colors), prefixed by a hash +character ("#").

+

Example configuration:

+
+
+
color_good = "#00FF00"
+
+

Likewise, you can use the color_separator directive to specify the color that +will be used to paint the separator bar. The separator is always output in +color, even when colors are disabled by the colors directive.

+

The interval directive specifies the time in seconds for which i3status will +sleep before printing the next status line.

+

Using output_format you can chose which format strings i3status should +use in its output. Currently available are:

+
+
+dzen2 +
+
+

+Dzen is a general purpose messaging, notification and menuing program for X11. +It was designed to be scriptable in any language and integrate well with window +managers like dwm, wmii and xmonad though it will work with any windowmanger +

+
+
+xmobar +
+
+

+xmobar is a minimalistic, text based, status bar. It was designed to work +with the xmonad Window Manager. +

+
+
+none +
+
+

+Does not use any color codes. Separates values by the pipe symbol. This should +be used with i3bar and can be used for custom scripts. +

+
+
+
+
+

5.2. IPv6

+

This module gets the IPv6 address used for outgoing connections (that is, the +best available public IPv6 address on your computer).

+

Example format_up: %ip

+

Example format_down no IPv6

+
+
+

5.3. Disk

+

Gets used, free, available and total amount of bytes on the given mounted filesystem.

+

Example order: disk /mnt/usbstick

+

Example format: %free (%avail)/ %total

+
+
+

5.4. Run-watch

+

Expands the given path to a pidfile and checks if the process ID found inside +is valid (that is, if the process is running). You can use this to check if +a specific application, such as a VPN client or your DHCP client is running.

+

Example order: run_watch DHCP

+
+
+

5.5. Wireless

+

Gets the link quality and ESSID of the given wireless network interface. You +can specify different format strings for the network being connected or not +connected.

+

Example order: wireless wlan0

+

Example format: W: (%quality at %essid, %bitrate) %ip

+
+
+

5.6. Ethernet

+

Gets the IP address and (if possible) the link speed of the given ethernet +interface. Getting the link speed requires the cap_net_admin capability. Set +it using setcap cap_net_admin=ep $(which i3status).

+

Example order: ethernet eth0

+

Example format: E: %ip (%speed)

+
+
+

5.7. Battery

+

Gets the status (charging, discharging, running), percentage and remaining +time of the given battery. If you want to use the last full capacity instead +of the design capacity (when using the design capacity, it may happen that +your battery is at 23% when fully charged because it’s old. In general, I +want to see it this way, because it tells me how worn off my battery is.), +just specify last_full_capacity = true.

+

Example order: battery 0

+

Example format: %status %remaining

+
+
+

5.8. CPU-Temperature

+

Gets the temperature of the given thermal zone.

+

Example order: cpu_temperature 0

+

Example format: T: %degrees °C

+
+
+

5.9. CPU Usage

+

Gets the percentual CPU usage from /proc/stat.

+

Example order: cpu_usage

+

Example format: %usage

+
+
+

5.10. Load

+

Gets the system load (number of processes waiting for CPU time in the last +5, 10 and 15 minutes).

+

Example order: load

+

Example format: %5min %10min %15min

+
+
+

5.11. Time

+

Formats the current system time. See strftime(3) for the format.

+

Example order: time

+

Example format: %Y-%m-%d %H:%M:%S

+
+
+

5.12. DDate

+

Outputs the current discordian date in user-specified format. See ddate(1) for +details on the format string. +Note: Neither %. nor %X are implemented yet.

+

Example order: ddate

+

Example format: %{%a, %b %d%}, %Y%N - %H

+
+
+

5.13. Volume

+

Outputs the volume of the specified mixer on the specified device. Works only +on Linux because it uses ALSA.

+

Example order: volume master

+

Example format: ♪: %volume

+

Example configuration:

+
+
+
volume master {
+        format = "♪: %volume"
+        device = "default"
+        mixer = "Master"
+        mixer_idx = 0
+}
+
+
+
+
+
+

6. Using i3status with dzen2

+
+

After installing dzen2, you can directly use it with i3status. Just ensure that +output_format is set to dzen2.

+

Example for usage of i3status with dzen2:

+
+
+
i3status | dzen2 -fg white -ta r -w 1280 \
+-fn "-misc-fixed-medium-r-normal--13-120-75-75-C-70-iso8859-1"
+
+
+
+
+

7. Using i3status with xmobar

+
+

To get xmobar to start, you might need to copy the default configuration +file to ~/.xmobarrc. Also, ensure that the output_format option for i3status +is set to xmobar.

+

Example for usage of i3status with xmobar:

+
+
+
i3status | xmobar -o -t "%StdinReader%" -c "[Run StdinReader]"
+
+
+
+
+

8. SEE ALSO

+
+

strftime(3), date(1), glob(3), dzen2(1), xmobar(1)

+
+
+
+

9. AUTHORS

+
+

Michael Stapelberg and contributors

+

Thorsten Toepper

+

Baptiste Daroussin

+

Axel Wagner

+

Fernando Tarlá Cardoso Lemos

+
+
+
+
+ + + diff --git a/docs/4.0/ipc.html b/docs/4.0/ipc.html new file mode 100644 index 0000000..3a3cb87 --- /dev/null +++ b/docs/4.0/ipc.html @@ -0,0 +1,844 @@ + + + + + + +i3: IPC interface (interprocess communication) + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes how to interface with i3 from a separate process. This +is useful for example to remote-control i3 (to write test cases for example) or +to get various information like the current workspaces to implement an external +workspace bar.

+

The method of choice for IPC in our case is a unix socket because it has very +little overhead on both sides and is usually available without headaches in +most languages. In the default configuration file, the ipc-socket gets created +in /tmp/i3-%u/ipc-socket.%p where %u is your UNIX username and %p is the +PID of i3.

+

All i3 utilities, like i3-msg and i3-input will read the I3_SOCKET_PATH +X11 property, stored on the X11 root window.

+
+
+
+

1. Establishing a connection

+
+

To establish a connection, simply open the IPC socket. The following code +snippet illustrates this in Perl:

+
+
+
use IO::Socket::UNIX;
+my $sock = IO::Socket::UNIX->new(Peer => '/tmp/i3-ipc.sock');
+
+
+
+
+

2. Sending messages to i3

+
+

To send a message to i3, you have to format in the binary message format which +i3 expects. This format specifies a magic string in the beginning to ensure +the integrity of messages (to prevent follow-up errors). Following the magic +string comes the length of the payload of the message as 32-bit integer, and +the type of the message as 32-bit integer (the integers are not converted, so +they are in native byte order).

+

The magic string currently is "i3-ipc" and will only be changed when a change +in the IPC API is done which breaks compatibility (we hope that we don’t need +to do that).

+

Currently implemented message types are the following:

+
+
+COMMAND (0) +
+
+

+ The payload of the message is a command for i3 (like the commands you + can bind to keys in the configuration file) and will be executed + directly after receiving it. There is no reply to this message. +

+
+
+GET_WORKSPACES (1) +
+
+

+ Gets the current workspaces. The reply will be a JSON-encoded list of + workspaces (see the reply section). +

+
+
+SUBSCRIBE (2) +
+
+

+ Subscribes your connection to certain events. See [events] for a + description of this message and the concept of events. +

+
+
+GET_OUTPUTS (3) +
+
+

+ Gets the current outputs. The reply will be a JSON-encoded list of outputs + (see the reply section). +

+
+
+GET_TREE (4) +
+
+

+ Gets the layout tree. i3 uses a tree as data structure which includes + every container. The reply will be the JSON-encoded tree (see the reply + section). +

+
+
+

So, a typical message could look like this:

+
+
+
"i3-ipc" <message length> <message type> <payload>
+
+

Or, as a hexdump:

+
+
+
00000000  69 33 2d 69 70 63 04 00  00 00 00 00 00 00 65 78  |i3-ipc........ex|
+00000010  69 74 0a                                          |it.|
+
+

To generate and send such a message, you could use the following code in Perl:

+
+
+
sub format_ipc_command {
+    my ($msg) = @_;
+    my $len;
+    # Get the real byte count (vs. amount of characters)
+    { use bytes; $len = length($msg); }
+    return "i3-ipc" . pack("LL", $len, 0) . $msg;
+}
+
+$sock->write(format_ipc_command("exit"));
+
+
+
+
+

3. Receiving replies from i3

+
+

Replies from i3 usually consist of a simple string (the length of the string +is the message_length, so you can consider them length-prefixed) which in turn +contain the JSON serialization of a data structure. For example, the +GET_WORKSPACES message returns an array of workspaces (each workspace is a map +with certain attributes).

+
+

3.1. Reply format

+

The reply format is identical to the normal message format. There also is +the magic string, then the message length, then the message type and the +payload.

+

The following reply types are implemented:

+
+
+COMMAND (0) +
+
+

+ Confirmation/Error code for the COMMAND message. +

+
+
+GET_WORKSPACES (1) +
+
+

+ Reply to the GET_WORKSPACES message. +

+
+
+SUBSCRIBE (2) +
+
+

+ Confirmation/Error code for the SUBSCRIBE message. +

+
+
+GET_OUTPUTS (3) +
+
+

+ Reply to the GET_OUTPUTS message. +

+
+
+GET_TREE (4) +
+
+

+ Reply to the GET_TREE message. +

+
+
+
+
+

3.2. COMMAND reply

+

The reply consists of a single serialized map. At the moment, the only +property is success (bool), but this will be expanded in future versions.

+

Example:

+
+
+
{ "success": true }
+
+
+
+

3.3. GET_WORKSPACES reply

+

The reply consists of a serialized list of workspaces. Each workspace has the +following properties:

+
+
+num (integer) +
+
+

+ The logical number of the workspace. Corresponds to the command + to switch to this workspace. +

+
+
+name (string) +
+
+

+ The name of this workspace (by default num+1), as changed by the + user. Encoded in UTF-8. +

+
+
+visible (boolean) +
+
+

+ Whether this workspace is currently visible on an output (multiple + workspaces can be visible at the same time). +

+
+
+focused (boolean) +
+
+

+ Whether this workspace currently has the focus (only one workspace + can have the focus at the same time). +

+
+
+urgent (boolean) +
+
+

+ Whether a window on this workspace has the "urgent" flag set. +

+
+
+rect (map) +
+
+

+ The rectangle of this workspace (equals the rect of the output it + is on), consists of x, y, width, height. +

+
+
+output (string) +
+
+

+ The video output this workspace is on (LVDS1, VGA1, …). +

+
+
+

Example:

+
+
+
[
+ {
+  "num": 0,
+  "name": "1",
+  "visible": true,
+  "focused": true,
+  "urgent": false,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  },
+  "output": "LVDS1"
+ },
+ {
+  "num": 1,
+  "name": "2",
+  "visible": false,
+  "focused": false,
+  "urgent": false,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  },
+  "output": "LVDS1"
+ }
+]
+
+
+
+

3.4. SUBSCRIBE reply

+

The reply consists of a single serialized map. The only property is +success (bool), indicating whether the subscription was successful (the +default) or whether a JSON parse error occurred.

+

Example:

+
+
+
{ "success": true }
+
+
+
+

3.5. GET_OUTPUTS reply

+

The reply consists of a serialized list of outputs. Each output has the +following properties:

+
+
+name (string) +
+
+

+ The name of this output (as seen in xrandr(1)). Encoded in UTF-8. +

+
+
+active (boolean) +
+
+

+ Whether this output is currently active (has a valid mode). +

+
+
+current_workspace (integer) +
+
+

+ The current workspace which is visible on this output. null if the + output is not active. +

+
+
+rect (map) +
+
+

+ The rectangle of this output (equals the rect of the output it + is on), consists of x, y, width, height. +

+
+
+

Example:

+
+
+
[
+ {
+  "name": "LVDS1",
+  "active": true,
+  "current_workspace": 4,
+  "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+  }
+ },
+ {
+  "name": "VGA1",
+  "active": true,
+  "current_workspace": 1,
+  "rect": {
+   "x": 1280,
+   "y": 0,
+   "width": 1280,
+   "height": 1024
+  },
+ }
+]
+
+
+
+

3.6. GET_TREE reply

+

The reply consists of a serialized tree. Each node in the tree (representing +one container) has at least the properties listed below. While the nodes might +have more properties, please do not use any properties which are not documented +here. They are not yet finalized and will probably change!

+
+
+id (integer) +
+
+

+ The internal ID (actually a C pointer value) of this container. Do not + make any assumptions about it. You can use it to (re-)identify and + address containers when talking to i3. +

+
+
+name (string) +
+
+

+ The internal name of this container. For all containers which are part + of the tree structure down to the workspace contents, this is set to a + nice human-readable name of the container. + For all other containers, the content is not defined (yet). +

+
+
+border (string) +
+
+

+ Can be either "normal", "none" or "1pixel", dependending on the + container’s border style. +

+
+
+layout (string) +
+
+

+ Can be either "default", "stacked", "tabbed", "dockarea" or "output". + Other values might be possible in the future, should we add new + layouts. +

+
+
+orientation (string) +
+
+

+ Can be either "none" (for non-split containers), "horizontal" or + "vertical". +

+
+
+percent (float) +
+
+

+ The percentage which this container takes in its parent. A value of + null means that the percent property does not make sense for this + container, for example for the root container. +

+
+
+rect (map) +
+
+

+ The absolute display coordinates for this container. Display + coordinates means that when you have two 1600x1200 monitors on a single + X11 Display (the standard way), the coordinates of the first window on + the second monitor are { "x": 1600, "y": 0, "width": 1600, "height": + 1200 }. +

+
+
+window_rect (map) +
+
+

+ The coordinates of the actual client window inside its container. + These coordinates are relative to the container and do not include the + window decoration (which is actually rendered on the parent container). + So, when using the default layout, you will have a 2 pixel border on + each side, making the window_rect { "x": 2, "y": 0, "width": 632, + "height": 366 } (for example). +

+
+
+geometry (map) +
+
+

+ The original geometry the window specified when i3 mapped it. Used when + switching a window to floating mode, for example. +

+
+
+urgent (bool) +
+
+

+ Whether this container (window or workspace) has the urgency hint set. +

+
+
+focused (bool) +
+
+

+ Whether this container is currently focused. +

+
+
+

Please note that in the following example, I have left out some keys/values +which are not relevant for the type of the node. Otherwise, the example would +be by far too long (it already is quite long, despite showing only 1 window and +one dock window).

+

It is useful to have an overview of the structure before taking a look at the +JSON dump:

+
    +
  • +

    +root +

    +
      +
    • +

      +LVDS1 +

      +
        +
      • +

        +topdock +

        +
        • +
      • +

        +content +

        +
          +
        • +

          +workspace 1 +

          +
            +
          • +

            +window 1 +

            +
            • +
          +
          • +
        +
        • +
      • +

        +bottomdock +

        +
          +
        • +

          +dock window 1 +

          +
          • +
        +
        • +
      +
      • +
    • +

      +VGA1 +

      +
      • +
    +
    • +
+

Example:

+
+
+
{
+ "id": 6875648,
+ "name": "root",
+ "rect": {
+   "x": 0,
+   "y": 0,
+   "width": 1280,
+   "height": 800
+ },
+ "nodes": [
+
+   {
+    "id": 6878320,
+    "name": "LVDS1",
+    "layout": "output",
+    "rect": {
+      "x": 0,
+      "y": 0,
+      "width": 1280,
+      "height": 800
+    },
+    "nodes": [
+
+      {
+       "id": 6878784,
+       "name": "topdock",
+       "layout": "dockarea",
+       "orientation": "vertical",
+       "rect": {
+         "x": 0,
+         "y": 0,
+         "width": 1280,
+         "height": 0
+       },
+      },
+
+      {
+       "id": 6879344,
+       "name": "content",
+       "rect": {
+         "x": 0,
+         "y": 0,
+         "width": 1280,
+         "height": 782
+       },
+       "nodes": [
+
+         {
+          "id": 6880464,
+          "name": "1",
+          "orientation": "horizontal",
+          "rect": {
+            "x": 0,
+            "y": 0,
+            "width": 1280,
+            "height": 782
+          },
+          "floating_nodes": [],
+          "nodes": [
+
+            {
+             "id": 6929968,
+             "name": "#aa0000",
+             "border": "normal",
+             "percent": 1,
+             "rect": {
+               "x": 0,
+               "y": 18,
+               "width": 1280,
+               "height": 782
+             }
+            }
+
+          ]
+         }
+
+       ]
+      },
+
+      {
+       "id": 6880208,
+       "name": "bottomdock",
+       "layout": "dockarea",
+       "orientation": "vertical",
+       "rect": {
+         "x": 0,
+         "y": 782,
+         "width": 1280,
+         "height": 18
+       },
+       "nodes": [
+
+         {
+          "id": 6931312,
+          "name": "#00aa00",
+          "percent": 1,
+          "rect": {
+            "x": 0,
+            "y": 782,
+            "width": 1280,
+            "height": 18
+          }
+         }
+
+       ]
+      }
+    ]
+   }
+ ]
+}
+
+
+
+
+
+

4. Events

+
+

To get informed when certain things happen in i3, clients can subscribe to +events. Events consist of a name (like "workspace") and an event reply type +(like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format +as replies to specific commands. However, the highest bit of the message type +is set to 1 to indicate that this is an event reply instead of a normal reply.

+

Caveat: As soon as you subscribe to an event, it is not guaranteed any longer +that the requests to i3 are processed in order. This means, the following +situation can happen: You send a GET_WORKSPACES request but you receive a +"workspace" event before receiving the reply to GET_WORKSPACES. If your +program does not want to cope which such kinds of race conditions (an +event based library may not have a problem here), I suggest you create a +separate connection to receive events.

+
+

4.1. Subscribing to events

+

By sending a message of type SUBSCRIBE with a JSON-encoded array as payload +you can register to an event.

+

Example:

+
+
+
type: SUBSCRIBE
+payload: [ "workspace", "focus" ]
+
+
+
+

4.2. Available events

+

The numbers in parenthesis is the event type (keep in mind that you need to +strip the highest bit first).

+
+
+workspace (0) +
+
+

+ Sent when the user switches to a different workspace, when a new + workspace is initialized or when a workspace is removed (because the + last client vanished). +

+
+
+output (1) +
+
+

+ Sent when RandR issues a change notification (of either screens, + outputs, CRTCs or output properties). +

+
+
+

Example:

+
+
+
# the appropriate 4 bytes read from the socket are stored in $input
+
+# unpack a 32-bit unsigned integer
+my $message_type = unpack("L", $input);
+
+# check if the highest bit is 1
+my $is_event = (($message_type >> 31) == 1);
+
+# use the other bits
+my $event_type = ($message_type & 0x7F);
+
+if ($is_event) {
+  say "Received event of type $event_type";
+}
+
+
+
+

4.3. workspace event

+

This event consists of a single serialized map containing a property +change (string) which indicates the type of the change ("focus", "init", +"empty", "urgent").

+

Example:

+
+
+
{ "change": "focus" }
+
+
+
+

4.4. output event

+

This event consists of a single serialized map containing a property +change (string) which indicates the type of the change (currently only +"unspecified").

+

Example:

+
+
+
{ "change": "unspecified" }
+
+
+
+
+
+

5. See also

+
+

For some languages, libraries are available (so you don’t have to implement +all this on your own). This list names some (if you wrote one, please let me +know):

+
+
+C +
+
+

+ i3 includes a headerfile i3/ipc.h which provides you all constants. + However, there is no library yet. +

+
+
+Ruby +
+
+

+ http://github.com/badboy/i3-ipc +

+
+
+Perl +
+
+

+ http://search.cpan.org/search?query=AnyEvent::I3 +

+
+
+Python +
+
+

+ http://github.com/thepub/i3ipc +

+
+
+
+
+
+
+ + + diff --git a/docs/4.0/keyboard-layer1.png b/docs/4.0/keyboard-layer1.png new file mode 100644 index 0000000..52ffae0 Binary files /dev/null and b/docs/4.0/keyboard-layer1.png differ diff --git a/docs/4.0/keyboard-layer1.svg b/docs/4.0/keyboard-layer1.svg new file mode 100644 index 0000000..109c19a --- /dev/null +++ b/docs/4.0/keyboard-layer1.svg @@ -0,0 +1,969 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Caps Lock + + + + + + + + + + + + Shift + + + + Shift + + + + + + + + + + + + fullscreen + tabbedlayout + defaultlayout + dmenu + focus floating/tiling + left + down + up + right + splithoriz. + Mod1 + openterminal + splitvert. + stackedlayout + focusparent + resizemode + T + + diff --git a/docs/4.0/keyboard-layer2.png b/docs/4.0/keyboard-layer2.png new file mode 100644 index 0000000..83616d9 Binary files /dev/null and b/docs/4.0/keyboard-layer2.png differ diff --git a/docs/4.0/keyboard-layer2.svg b/docs/4.0/keyboard-layer2.svg new file mode 100644 index 0000000..70cc602 --- /dev/null +++ b/docs/4.0/keyboard-layer2.svg @@ -0,0 +1,896 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Caps Lock + + + + + + + + + + + + + + + + + + + + + Shift + + + + Shift + + + + + + + + + + + + toggle tiling/floating + killwindow + exiti3 + restarti3 + moveleft + movedown + moveup + moveright + Mod1 + + diff --git a/docs/4.0/modes.png b/docs/4.0/modes.png new file mode 100644 index 0000000..656a6db Binary files /dev/null and b/docs/4.0/modes.png differ diff --git a/docs/4.0/multi-monitor.html b/docs/4.0/multi-monitor.html new file mode 100644 index 0000000..ee42703 --- /dev/null +++ b/docs/4.0/multi-monitor.html @@ -0,0 +1,108 @@ + + + + + + +i3: The multi-monitor situation + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

…or: oh no, I have an nVidia graphics card!

+
+
+
+

1. The quick fix

+
+

If you are using the nVidia binary graphics driver (also known as blob) +you need to use the --force-xinerama flag (in your .xsession) when starting +i3, like so:

+
+
Example:
+
+
exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
+
+
+
+
+

2. The explanation

+
+

Starting with version 3.ε, i3 uses the RandR (Rotate and Resize) API instead +of Xinerama. The reason for this, is that RandR provides more information +about your outputs and connected screens than Xinerama does. To be specific, +the code which handled on-the-fly screen reconfiguration (meaning without +restarting the X server) was a very messy heuristic and most of the time did +not work correctly — that is just not possible with the little information +Xinerama offers (just a list of screen resolutions, no identifiers for the +screens or any additional information). Xinerama simply was not designed +for dynamic configuration.

+

So RandR came along, as a more powerful alternative (RandR 1.2 to be specific). +It offers all of Xinerama’s possibilities and lots more. Using the RandR API +made our code much more robust and clean. Also, you can now reliably assign +workspaces to output names instead of some rather unreliable screen identifier +(position inside the list of screens, which could change, and so on…).

+

As RandR has been around for about three years as of this writing, it seemed +like a very good idea to us, and it still is a very good one. What we did not +expect, however, was the nVidia binary driver. It still does not support RandR +(as of March 2010), even though nVidia has announced that it will support RandR +eventually. What does this mean for you, if you are stuck with the binary +driver for some reason (say the free drivers don’t work with your card)? First +of all, you are stuck with TwinView and cannot use xrandr. While this ruins +the user experience, the more grave problem is that the nVidia driver not only +does not support dynamic configuration using RandR, it also does not expose +correct multi-monitor information via the RandR API. So, in some setups, i3 +will not find any screens; in others, it will find one large screen which +actually contains both of your physical screens (but it will not know that +these are two screens).

+

For this very reason, we decided to implement the following workaround: As +long as the nVidia driver does not support RandR, an option called +--force-xinerama is available in i3. This option gets the list of screens +once when starting, and never updates it. As the nVidia driver cannot do +dynamic configuration anyways, this is not a big deal.

+
+
+
+

3. See also

+
+

For more information on how to use multi-monitor setups, see the i3 User’s +Guide.

+
+
+
+
+ + + diff --git a/docs/4.0/refcard.pdf b/docs/4.0/refcard.pdf new file mode 100644 index 0000000..3ff733d Binary files /dev/null and b/docs/4.0/refcard.pdf differ diff --git a/docs/4.0/repositories.html b/docs/4.0/repositories.html new file mode 100644 index 0000000..db62780 --- /dev/null +++ b/docs/4.0/repositories.html @@ -0,0 +1,120 @@ + + + + + + +i3: Debian and Ubuntu repositories + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+

1. When should you use our repositories?

+
+

In general, you should use the repositories of your distribution. Adding +third-party repositories to your /etc/sources.list has security implications +and makes your apt-get update take longer. However, in some cases, using our +repositories makes sense:

+
+
+You are using Debian stable +
+
+

+ The latest version of i3 will be in Debian testing quite soon. The version + in Debian stable can be old, however (we cannot update it after stable has + been released). The best way is to add Debian testing and tell apt to + prefer Debian stable. You should not use our repository. +

+
+
+You are using Ubuntu +
+
+

+ Only a handful of packages are maintained by Ubuntu developers. The rest is + synchronized periodically from Debian, every 6 months. Therefore, Ubuntu + often includes old versions of i3. You should use our Ubuntu repository. +

+
+
+You want the latest i3 development version +
+
+

+ If you are using Debian (Debian-derived systems might work, too) and want + the latest development version of i3, you should use our Debian repository. +

+
+
+
+
+
+

2. Ubuntu repository

+
+

The Ubuntu repository is provided by sur5r and contains the latest stable release +of i3. To use it, run the following commands:

+
+
+
# echo 'deb http://debian.sur5r.net/i3/ natty universe' >> /etc/apt/sources.list
+# apt-get update
+# apt-get install i3
+
+

The following Ubuntu versions are currently available: lucid, maverick, natty.

+
+
+
+

3. Debian repository

+
+

Our Debian repository contains packages which are automatically built a few +minutes after every commit. To use it, run the following commands:

+
+
+
# echo 'deb http://build.i3wm.org/debian/i3-wm sid main' >> /etc/apt/sources.list
+# apt-get update
+# apt-get install i3-wm
+
+

To ensure that the autobuilt i3 packages will be preferred to the packages of +your distribution, put the following entry at the beginning of your +/etc/apt/preferences:

+
+
+
Package: *
+Pin: origin "build.i3wm.org"
+Pin-Priority: 1001
+
+

Then, install i3-wm.

+
+
+
+
+ + + diff --git a/docs/4.0/single_terminal.png b/docs/4.0/single_terminal.png new file mode 100644 index 0000000..4fe918c Binary files /dev/null and b/docs/4.0/single_terminal.png differ diff --git a/docs/4.0/snapping.png b/docs/4.0/snapping.png new file mode 100644 index 0000000..65fe6e4 Binary files /dev/null and b/docs/4.0/snapping.png differ diff --git a/docs/4.0/stacklimit.png b/docs/4.0/stacklimit.png new file mode 100644 index 0000000..ab5bed7 Binary files /dev/null and b/docs/4.0/stacklimit.png differ diff --git a/docs/4.0/tree-layout1.png b/docs/4.0/tree-layout1.png new file mode 100644 index 0000000..ee69f1a Binary files /dev/null and b/docs/4.0/tree-layout1.png differ diff --git a/docs/4.0/tree-layout2.png b/docs/4.0/tree-layout2.png new file mode 100644 index 0000000..5cbadde Binary files /dev/null and b/docs/4.0/tree-layout2.png differ diff --git a/docs/4.0/tree-shot1.png b/docs/4.0/tree-shot1.png new file mode 100644 index 0000000..3bbeae1 Binary files /dev/null and b/docs/4.0/tree-shot1.png differ diff --git a/docs/4.0/tree-shot2.png b/docs/4.0/tree-shot2.png new file mode 100644 index 0000000..f003264 Binary files /dev/null and b/docs/4.0/tree-shot2.png differ diff --git a/docs/4.0/tree-shot3.png b/docs/4.0/tree-shot3.png new file mode 100644 index 0000000..fe4c11e Binary files /dev/null and b/docs/4.0/tree-shot3.png differ diff --git a/docs/4.0/tree-shot4.png b/docs/4.0/tree-shot4.png new file mode 100644 index 0000000..61e8c91 Binary files /dev/null and b/docs/4.0/tree-shot4.png differ diff --git a/docs/4.0/two_columns.png b/docs/4.0/two_columns.png new file mode 100644 index 0000000..6dc8c40 Binary files /dev/null and b/docs/4.0/two_columns.png differ diff --git a/docs/4.0/two_terminals.png b/docs/4.0/two_terminals.png new file mode 100644 index 0000000..20b45ac Binary files /dev/null and b/docs/4.0/two_terminals.png differ diff --git a/docs/4.0/userguide.html b/docs/4.0/userguide.html new file mode 100644 index 0000000..513cb9e --- /dev/null +++ b/docs/4.0/userguide.html @@ -0,0 +1,1206 @@ + + + + + + +i3: i3 User’s Guide + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document contains all the information you need to configure and use the i3 +window manager. If it does not, please contact us on IRC (preferred) or post your +question(s) on the mailing list.

+
+
+
+

1. Default keybindings

+
+

For the "too long; didn’t read" people, here is an overview of the default +keybindings (click to see the full size image):

+

Keys to use with mod (alt):

+

+ +Keys to use with mod (alt) + +

+

Keys to use with Shift+mod:

+

+ +Keys to use with Shift+mod + +

+

The red keys are the modifiers you need to press (by default), the blue keys +are your homerow.

+
+
+
+

2. Using i3

+
+

Throughout this guide, the keyword mod will be used to refer to the +configured modifier. This is the alt key (Mod1) by default, with windows (Mod4) +being a popular alternative.

+
+

2.1. Opening terminals and moving around

+

One very basic operation is opening a new terminal. By default, the keybinding +for this is mod+Enter, that is Alt+Enter in the default configuration. By +pressing mod+Enter, a new terminal will be opened. It will fill the whole +space available on your screen.

+

+Single terminal +

+

If you now open another terminal, i3 will place it next to the current one, +splitting the screen size in half. Depending on your monitor, i3 will put the +created window beside the existing window (on wide displays) or below the +existing window (rotated displays).

+

+Two terminals +

+

To move the focus between the two terminals, you can use the direction keys +which you may know from the editor vi. However, in i3, your homerow is used +for these keys (in vi, the keys are shifted to the left by one for +compatibility with most keyboard layouts). Therefore, mod+J is left, mod+K +is down, mod+L is up and mod+; is right. So, to switch between the +terminals, use mod+K or mod+L. Of course, you can also use the arrow keys.

+

At the moment, your workspace is split (it contains two terminals) in a +specific direction (horizontal by default). Every window can be split +horizontally or vertically again, just like the workspace. The terminology is +"window" for a container that actually contains an X11 window (like a terminal +or browser) and "split container" for containers that consist of one or more +windows.

+

TODO: picture of the tree

+

To split a window vertically, press mod+v. To split it horizontally, press +mod+h.

+
+
+

2.2. Changing the container layout

+

A split container can have one of the following layouts:

+
+
+default +
+
+

+Windows are sized so that every window gets an equal amount of space in the +container. +

+
+
+stacking +
+
+

+Only the focused window in the container is displayed. You get a list of +windows at the top of the container. +

+
+
+tabbed +
+
+

+The same principle as stacking, but the list of windows at the top is only +a single line which is vertically split. +

+
+
+

To switch modes, press mod+e for default, mod+h for stacking and +mod+w for tabbed.

+

+Container modes +

+
+
+

2.3. Toggling fullscreen mode for a window

+

To display a window in fullscreen mode or to go out of fullscreen mode again, +press mod+f.

+

There is also a global fullscreen mode in i3 in which the client will span all +available outputs.

+
+
+

2.4. Opening other applications

+

Aside from opening applications from a terminal, you can also use the handy +dmenu which is opened by pressing mod+d by default. Just type the name +(or a part of it) of the application which you want to open. The corresponding +application has to be in your $PATH for this to work.

+

Additionally, if you have applications you open very frequently, you can +create a keybinding for starting the application directly. See the section +[configuring] for details.

+
+
+

2.5. Closing windows

+

If an application does not provide a mechanism for closing (most applications +provide a menu, the escape key or a shortcut like Control+W to close), you +can press mod+Shift+q to kill a window. For applications which support +the WM_DELETE protocol, this will correctly close the application (saving +any modifications or doing other cleanup). If the application doesn’t support +the WM_DELETE protocol your X server will kill the window and the behaviour +depends on the application.

+
+
+

2.6. Using workspaces

+

Workspaces are an easy way to group a set of windows. By default, you are on +the first workspace, as the bar on the bottom left indicates. To switch to +another workspace, press mod+num where num is the number of the workspace +you want to use. If the workspace does not exist yet, it will be created.

+

A common paradigm is to put the web browser on one workspace, communication +applications (mutt, irssi, …) on another one, and the ones with which you +work, on the third one. Of course, there is no need to follow this approach.

+

If you have multiple screens, a workspace will be created on each screen at +startup. If you open a new workspace, it will be bound to the screen you +created it on. When you switch to a workspace on another screen, i3 will set +focus to that screen.

+
+
+

2.7. Moving windows to workspaces

+

To move a window to another workspace, simply press mod+Shift+num where +num is (like when switching workspaces) the number of the target workspace. +Similarly to switching workspaces, the target workspace will be created if +it does not yet exist.

+
+
+

2.8. Resizing

+

The easiest way to resize a container is by using the mouse: Grab the border +and move it to the wanted size.

+

See [resizingconfig] for how to configure i3 to be able to resize +columns/rows with your keyboard.

+
+
+

2.9. Restarting i3 inplace

+

To restart i3 inplace (and thus get into a clean state if there is a bug, or +to upgrade to a newer version of i3) you can use mod+Shift+r.

+
+
+

2.10. Exiting i3

+

To cleanly exit i3 without killing your X server, you can use mod+Shift+e.

+
+
+

2.11. Floating

+

Floating mode is the opposite of tiling mode. The position and size of a window +are not managed by i3, but by you. Using this mode violates the tiling +paradigm but can be useful for some corner cases like "Save as" dialog +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 +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].

+

For resizing floating windows with your keyboard, see [resizingconfig].

+

Floating windows are always on top of tiling windows.

+
+
+
+
+

3. Tree

+
+

i3 stores all information about the X11 outputs, workspaces and layout of the +windows on them in a tree. The root node is the X11 root window, followed by +the X11 outputs, then dock areas and a content container, then workspaces and +finally the windows themselve. In previous versions of i3 we had multiple lists +(of outputs, workspaces) and a table for each workspace. That approach turned +out to be complicated to use (snapping), understand and implement.

+
+

3.1. The tree consists of Containers

+

The building blocks of our tree are so called Containers. A Container can +host a window (meaning an X11 window, one that you can actually see and use, +like a browser). Alternatively, it could contain one or more Containers. A +simple example is the workspace: When you start i3 with a single monitor, a +single workspace and you open two terminal windows, you will end up with a tree +like this:

+
+
+layout2 +
+
+
+
+shot4 +
+
Figure 1. Two terminals on standard workspace
+
+
+
+

3.2. Orientation and Split Containers

+

It is only natural to use so-called Split Containers in order to build a +layout when using a tree as data structure. In i3, every Container has an +orientation (horizontal, vertical or unspecified). So, in our example with the +workspace, the default orientation of the workspace Container is horizontal +(most monitors are widescreen nowadays). If you change the orientation to +vertical (mod+v in the default config) and then open two terminals, i3 will +configure your windows like this:

+
+
+shot2 +
+
Figure 2. Vertical Workspace Orientation
+
+

An interesting new feature of the tree branch is the ability to split anything: +Let’s assume you have two terminals on a workspace (with horizontal +orientation), focus is on the right terminal. Now you want to open another +terminal window below the current one. If you would just open a new terminal +window, it would show up to the right due to the horizontal workspace +orientation. Instead, press mod+v to create a Vertical Split Container (to +open a Horizontal Split Container, use mod+h). Now you can open a new +terminal and it will open below the current one:

+
+
+Layout +
+
+
+
+shot +
+
Figure 3. Vertical Split Container
+
+
+

You probably guessed it already: There is no limit on how deep your hierarchy +of splits can be.

+
+
+

3.3. Focus parent

+

Let’s stay with our example from above. We have a terminal on the left and two +vertically split terminals on the right, focus is on the bottom right one. When +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:

+
+
+shot3 +
+
Figure 4. Focus parent, then open new terminal
+
+
+
+
+
+

4. Configuring i3

+
+

This is where the real fun begins ;-). Most things are very dependant on your +ideal working environment so we can’t make reasonable defaults for them.

+

While not using a programming language for the configuration, i3 stays +quite flexible in regards to the things you usually want your window manager +to do.

+

For example, you can configure bindings to jump to specific windows, +you can set specific applications to start on specific workspaces, you can +automatically start applications, you can change the colors of i3, and you +can bind your keys to do useful things.

+

To change the configuration of i3, copy /etc/i3/config to ~/.i3/config +(or ~/.config/i3/config if you like the XDG directory scheme) and edit it +with a text editor.

+

On first start (and on all following starts, unless you have a configuration +file), i3 will offer you to create a configuration file. You can tell the +wizard to use either Alt (Mod1) or Windows (Mod4) as modifier in the config +file. Also, the created config file will use the key symbols of your current +keyboard layout. To start the wizard, use the command i3-config-wizard. +Please note that you must not have ~/.i3/config, otherwise the wizard will +exit.

+
+

4.1. Comments

+

It is possible and recommended to use comments in your configuration file to +properly document your setup for later reference. Comments are started with +a # and can only be used at the beginning of a line:

+

Examples:

+
+
+
# This is a comment
+
+
+
+

4.2. Fonts

+

i3 uses X core fonts (not Xft) for rendering window titles. You can use +xfontsel(1) to generate such a font description. To see special characters +(Unicode), you need to use a font which supports the ISO-10646 encoding.

+

If i3 cannot open the configured font, it will output an error in the logfile +and fall back to a working font.

+

Syntax:

+
+
+
font <X core font description>
+
+

Examples:

+
+
+
font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+
+
+
+

4.3. Keyboard bindings

+

A keyboard binding makes i3 execute a command (see below) upon pressing a +specific key. i3 allows you to bind either on keycodes or on keysyms (you can +also mix your bindings, though i3 will not protect you from overlapping ones).

+
    +
  • +

    +A keysym (key symbol) is a description for a specific symbol, like "a" + or "b", but also more strange ones like "underscore" instead of "_". These + are the ones you use in Xmodmap to remap your keys. To get the current + mapping of your keys, use xmodmap -pke. +

    +
    • +
  • +

    +Keycodes do not need to have a symbol assigned (handy for custom vendor + hotkeys on some notebooks) and they will not change their meaning as you + switch to a different keyboard layout (when using xmodmap). +

    +
    • +
+

My recommendation is: If you often switch keyboard layouts but you want to keep +your bindings in the same physical location on the keyboard, use keycodes. +If you don’t switch layouts, and want a clean and simple config file, use +keysyms.

+

Syntax:

+
+
+
bindsym [Modifiers+]keysym command
+bindcode [Modifiers+]keycode command
+
+

Examples:

+
+
+
# Fullscreen
+bindsym mod+f f
+
+# Restart
+bindsym mod+Shift+r restart
+
+# Notebook-specific hotkeys
+bindcode 214 exec /home/michael/toggle_beamer.sh
+
+

Available Modifiers:

+
+
+Mod1-Mod5, Shift, Control +
+
+

+Standard modifiers, see xmodmap(1) +

+
+
+Mode_switch +
+
+

+Unlike other window managers, i3 can use Mode_switch as a modifier. This allows +you to remap capslock (for example) to Mode_switch and use it for both: typing +umlauts or special characters and having some comfortably reachable key +bindings. For example, when typing, capslock+1 or capslock+2 for switching +workspaces is totally convenient. Try it :-). +

+
+
+
+
+

4.4. The floating modifier

+

To move floating windows with your mouse, you can either grab their titlebar +or configure the so called floating modifier which you can then press and +click anywhere in the window itself to move it. The most common setup is to +use the same key you use for managing windows (Mod1 for example). Then +you can press Mod1, click into a window using your left mouse button, and drag +it to the position you want.

+

When holding the floating modifier, you can resize a floating window by +pressing the right mouse button on it and moving around while holding it. If +you hold the shift button as well, the resize will be proportional.

+

Syntax:

+
+
+
floating_modifier <Modifiers>
+
+

Example:

+
+
+
floating_modifier Mod1
+
+
+
+

4.5. Orientation for new workspaces

+

New workspaces get a reasonable default orientation: Wide-screen monitors +(anything wider than high) get horizontal orientation, rotated monitors +(anything higher than wide) get vertical orientation.

+

With the default_orientation configuration directive, you can override that +behaviour.

+

Syntax:

+
+
+
default_orientation <horizontal|vertical|auto>
+
+

Example:

+
+
+
default_orientation vertical
+
+
+
+

4.6. Layout mode for new containers

+

This option determines in which mode new containers on workspace level will +start.

+

Syntax:

+
+
+
workspace_layout <default|stacking|tabbed>
+
+

Example:

+
+
+
workspace_layout tabbed
+
+
+
+

4.7. Border style for new windows

+

This option determines which border style new windows will have.

+

Syntax:

+
+
+
new_window <normal|1pixel|borderless>
+
+

Example:

+
+
+
new_window 1pixel
+
+
+
+

4.8. Arbitrary commands for specific windows (for_window)

+

With the for_window command, you can let i3 execute any command when it +encounters a specific window. This can be used to set windows to floating or to +change their border style, for example.

+

Syntax:

+
+
+
for_window [criteria] command
+
+

Examples:

+
+
+
# enable floating mode for all XTerm windows
+for_window [class="XTerm"] mode floating
+
+# Make all urxvts use a 1-pixel border:
+for_window [class="urxvt"] border 1pixel
+
+# A less useful, but rather funny example:
+# makes the window floating as soon as I change
+# directory to ~/work
+for_window [title="x200: ~/work"] mode floating
+
+
+
+

4.9. Variables

+

As you learned in the section about keyboard bindings, you will have +to configure lots of bindings containing modifier keys. If you want to save +yourself some typing and be able to change the modifier you use later, +variables can be handy.

+

Syntax:

+
+
+
set $name value
+
+

Example:

+
+
+
set $m Mod1
+bindsym $m+Shift+r restart
+
+

Variables are directly replaced in the file when parsing. There is no fancy +handling and there are 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).

+
+
+

4.10. Automatically putting clients on specific workspaces

+

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 +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]
+
+

Examples:

+
+
+
assign urxvt 2
+assign urxvt → 2
+assign urxvt → work
+assign "urxvt" → 2
+assign "urxvt/VIM" → 3
+assign "gecko" → 4
+
+

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.

+
+
+

4.11. Automatically starting applications on i3 startup

+

By using the exec keyword outside a keybinding, you can configure +which commands will be performed by i3 on initial startup. exec +commands will not run when restarting i3, if you need a command to run +also when restarting i3 you should use the exec_always +keyword. These commands will be run in order.

+

Syntax:

+
+
+
exec command
+exec_always command
+
+

Examples:

+
+
+
exec i3status | dzen2 -dock
+exec_always ~/my_script.sh
+
+
+
+

4.12. Automatically putting workspaces on specific screens

+

If you assign clients to workspaces, it might be handy to put the +workspaces on specific screens. Also, the assignment of workspaces to screens +will determine which workspace i3 uses for a new screen when adding screens +or when starting (e.g., by default it will use 1 for the first screen, 2 for +the second screen and so on).

+

Syntax:

+
+
+
workspace <number> output <output>
+
+

The output is the name of the RandR output you attach your screen to. On a +laptop, you might have VGA1 and LVDS1 as output names. You can see the +available outputs by running xrandr --current.

+

Examples:

+
+
+
workspace 1 output LVDS1
+workspace 5 output VGA1
+
+
+
+

4.13. Changing colors

+

You can change all colors which i3 uses to draw the window decorations.

+

Syntax:

+
+
+
colorclass border background text
+
+

Where colorclass can be one of:

+
+
+client.focused +
+
+

+ A client which currently has the focus. +

+
+
+client.focused_inactive +
+
+

+ A client which is the focused one of its container, but it does not have + the focus at the moment. +

+
+
+client.unfocused +
+
+

+ A client which is not the focused one of its container. +

+
+
+client.urgent +
+
+

+ A client which has its urgency hint activated. +

+
+
+bar.focused +
+
+

+ The current workspace in the bottom bar. +

+
+
+bar.unfocused +
+
+

+ All other workspaces in the bottom bar. +

+
+
+bar.urgent +
+
+

+ A workspace which has at least one client with an activated urgency hint. +

+
+
+

You can also specify the color to be used to paint the background of the client +windows. This color will be used to paint the window on top of which the client +will be rendered.

+

Syntax:

+
+
+
client.background color
+
+

Only clients that do not cover the whole area of this window expose the color +used to paint it. If you use a color other than black for your terminals, you +most likely want to set the client background color to the same color as your +terminal program’s background color to avoid black gaps between the rendered +area of the termianal and the i3 border.

+

Colors are in HTML hex format (#rrggbb), see the following example:

+

Examples:

+
+
+
# class        border  backgr. text
+client.focused #2F343A #900000 #FFFFFF
+
+

Note that for the window decorations, the color around the child window is the +background color, and the border color is only the two thin lines at the top of +the window.

+
+
+

4.14. Interprocess communication

+

i3 uses unix sockets to provide an IPC interface. This allows third-party +programs to get information from i3, such as the current workspaces +(to display a workspace bar), and to control i3.

+

The IPC socket is enabled by default and will be created in +/tmp/i3-%u/ipc-socket.%p where %u is your UNIX username and %p is the PID +of i3.

+

You can override the default path through the environment-variable I3SOCK or +by specifying the ipc-socket directive.

+

Examples:

+
+
+
ipc-socket /tmp/i3-ipc.sock
+
+

You can then use the i3-msg application to perform any command listed in +the next section.

+
+
+

4.15. Focus follows mouse

+

If you have a setup where your mouse usually is in your way (like a touchpad +on your laptop which you do not want to disable completely), you might want +to disable focus follows mouse and control focus only by using your keyboard. +The mouse will still be useful inside the currently active window (for example +to click on links in your browser window).

+

Syntax:

+
+
+
focus_follows_mouse <yes|no>
+
+

Example:

+
+
+
focus_follows_mouse no
+
+
+
+

4.16. Popups during fullscreen mode

+

When you are in fullscreen mode, some applications still open popup windows +(take Xpdf for example). This is because these applications may not be aware +that they are in fullscreen mode (they do not check the corresponding hint). +There are two things which are possible to do in this situation:

+
    +
  1. +

    +Just ignore the popup (don’t map it). This won’t interrupt you while you are + in fullscreen. However, some apps might react badly to this (deadlock until + you go out of fullscreen). +

    +
    2. +
  2. +

    +Leave fullscreen mode. This is the default. +

    +
    3. +
+

Syntax:

+
+
+
popup_during_fullscreen <ignore|leave_fullscreen>
+
+

Example:

+
+
+
popup_during_fullscreen ignore
+
+
+
+
+
+

5. List of commands

+
+
+

5.1. Splitting containers

+

The split command makes the current window a split container. Split containers +can contain multiple windows. Every split container has an orientation, it is +either split horizontally (a new window gets placed to the right of the current +one) or vertically (a new window gets placed below the current one).

+

If you apply this command to a split container with the same orientation, +nothing will happen. If you use a different orientation, the split container’s +orientation will be changed (if it does not have more than one window).

+

Syntax:

+
+
+
split <vertical|horizontal>
+
+

Example:

+
+
+
split vertical
+
+
+
+

5.2. Manipulating layout

+

Use layout default, layout stacking or layout tabbed to change the +current container layout to default, stacking or tabbed layout, respectively.

+

To make the current window (!) fullscreen, use fullscreen, to make +it floating (or tiling again) use floating enable respectively floating disable +(or floating toggle):

+

Examples:

+
+
+
bindsym mod+s layout stacking
+bindsym mod+l layout default
+bindsym mod+w layout tabbed
+
+# Toggle fullscreen
+bindsym mod+f fullscreen
+
+# Toggle floating/tiling
+bindsym mod+t floating toggle
+
+
+
+

5.3. Focusing/Moving containers

+

To change the focus, use the focus command: focus left, focus right, focus down and focus up.

+

There are a few special parameters you can use for the focus command:

+
+
+parent +
+
+

+ Sets focus to the Parent Container of the current Container. +

+
+
+child +
+
+

+ The opposite of focus parent, sets the focus to the last focused + child container. +

+
+
+floating +
+
+

+ Sets focus to the last focused floating container. +

+
+
+tiling +
+
+

+ Sets focus to the last focused tiling container. +

+
+
+mode_toggle +
+
+

+ Toggles between floating/tiling containers. +

+
+
+

For moving, use move left, move right, move down and move up.

+

Examples:

+
+
+
# Focus clients on the left, bottom, top, right:
+bindsym mod+j focus left
+bindsym mod+k focus down
+bindsym mod+l focus up
+bindsym mod+semicolon focus right
+
+# Focus parent container
+bindsym mod+u focus parent
+
+# Focus last floating/tiling container
+bindsym mod+g focus mode_toggle
+
+# Move client to the left, bottom, top, right:
+bindsym mod+j move left
+bindsym mod+k move down
+bindsym mod+l move up
+bindsym mod+semicolon move right
+
+
+
+

5.4. Changing workspaces/moving containers to workspaces

+

To change to a specific workspace, use the workspace command, followed by the +number or name of the workspace. To move containers to specific workspaces, use +move workspace.

+

You can also switch to the next and previous workspace with the commands +workspace next and workspace prev, which is handy, for example, if you have +workspace 1, 3, 4 and 9 and you want to cycle through them with a single key +combination.

+

Examples:

+
+
+
bindsym mod+1 workspace 1
+bindsym mod+2 workspace 2
+...
+
+bindsym mod+Shift+1 move workspace 1
+bindsym mod+Shift+2 move workspace 2
+...
+
+
+
+

5.5. Resizing containers/windows

+

If you want to resize containers/windows using your keyboard, you can use the +resize command, I recommend using it inside a so called mode:

+
+
Example: Configuration file, defining a mode for resizing
+
+
mode "resize" {
+        # These bindings trigger as soon as you enter the resize mode
+
+        # They resize the border in the direction you pressed, e.g.
+        # when pressing left, the window is resized so that it has
+        # more space on its left
+
+        bindsym j resize shrink left
+        bindsym Shift+j resize grow left
+
+        bindsym k resize grow bottom
+        bindsym Shift+k resize shrink bottom
+
+        bindsym l resize shrink top
+        bindsym Shift+l resize grow top
+
+        bindsym semicolon resize grow right
+        bindsym Shift+semicolon resize shrink right
+
+        bindcode 36 mode default
+}
+
+# Enter resize mode
+bindsym mod+r mode "resize"
+
+
+
+

5.6. Jumping to specific windows

+

Often when in a multi-monitor environment, you want to quickly jump to a +specific window. For example, while working on workspace 3 you may want to +jump to your mail client to email your boss that you’ve achieved some +important goal. Instead of figuring out how to navigate to your mailclient, +it would be more convenient to have a shortcut. You can use the focus command +with criteria for that.

+

Syntax:

+
+
+
[class="class"] focus
+[title="title"] focus
+
+

Examples:

+
+
+
# Get me to the next open VIM instance
+bindsym mod+a [class="urxvt" title="VIM"] focus
+
+
+
+

5.7. VIM-like marks (mark/goto)

+

This feature is like the jump feature: It allows you to directly jump to a +specific window (this means switching to the appropriate workspace and setting +focus to the windows). However, you can directly mark a specific window with +an arbitrary label and use it afterwards. You do not need to ensure that your +windows have unique classes or titles, and you do not need to change your +configuration file.

+

As the command needs to include the label with which you want to mark the +window, you cannot simply bind it to a key. i3-input is a tool created +for this purpose: It lets you input a command and sends the command to i3. It +can also prefix this command and display a custom prompt for the input dialog.

+

Syntax:

+
+
+
mark identifier
+[con_mark="identifier"] focus
+
+

Example (in a terminal):

+
+
+
$ i3-msg mark irssi
+$ i3-msg '[con_mark="irssi"] focus'
+
+
+
+

5.8. Changing border style

+

To change the border of the current client, you can use border normal to use the normal +border (including window title), border 1pixel 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.

+

Examples:

+
+
+
bindsym mod+t border normal
+bindsym mod+y border 1pixel
+bindsym mod+u border none
+
+
+
+

5.9. Reloading/Restarting/Exiting

+

You can make i3 reload its configuration file with reload. You can also +restart i3 inplace with the restart command to get it out of some weird state +(if that should ever happen) or to perform an upgrade without having to restart +your X session. To exit i3 properly, you can use the exit command, +however you don’t need to (simply killing your X session is fine as well).

+

Examples:

+
+
+
bindsym mod+Shift+r restart
+bindsym mod+Shift+w reload
+bindsym mod+Shift+e exit
+
+
+
+
+
+

6. Multiple monitors

+
+

As you can see in the goal list on the website, i3 was specifically developed +with support for multiple monitors in mind. This section will explain how to +handle multiple monitors.

+

When you have only one monitor, things are simple. You usually start with +workspace 1 on your monitor and open new ones as you need them.

+

When you have more than one monitor, each monitor will get an initial +workspace. The first monitor gets 1, the second gets 2 and a possible third +would get 3. When you switch to a workspace on a different monitor, i3 will +switch to that monitor and then switch to the workspace. This way, you don’t +need shortcuts to switch to a specific monitor, and you don’t need to remember +where you put which workspace. New workspaces will be opened on the currently +active monitor. It is not possible to have a monitor without a workspace.

+

The idea of making workspaces global is based on the observation that most +users have a very limited set of workspaces on their additional monitors. +They are often used for a specific task (browser, shell) or for monitoring +several things (mail, IRC, syslog, …). Thus, using one workspace on one monitor +and "the rest" on the other monitors often makes sense. However, as you can +create an unlimited number of workspaces in i3 and tie them to specific +screens, you can have the "traditional" approach of having X workspaces per +screen by changing your configuration (using modes, for example).

+
+

6.1. Configuring your monitors

+

To help you get going if you have never used multiple monitors before, here is +a short overview of the xrandr options which will probably be of interest to +you. It is always useful to get an overview of the current screen configuration. +Just run "xrandr" and you will get an output like the following:

+
+
+
$ xrandr
+Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192
+VGA1 disconnected (normal left inverted right x axis y axis)
+LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
+   1280x800       60.0*+   50.0
+   1024x768       85.0     75.0     70.1     60.0
+   832x624        74.6
+   800x600        85.1     72.2     75.0     60.3     56.2
+   640x480        85.0     72.8     75.0     59.9
+   720x400        85.0
+   640x400        85.1
+   640x350        85.1
+
+

Several things are important here: You can see that LVDS1 is connected (of +course, it is the internal flat panel) but VGA1 is not. If you have a monitor +connected to one of the ports but xrandr still says "disconnected", you should +check your cable, monitor or graphics driver.

+

The maximum resolution you can see at the end of the first line is the maximum +combined resolution of your monitors. By default, it is usually too low and has +to be increased by editing /etc/X11/xorg.conf.

+

So, say you connected VGA1 and want to use it as an additional screen:

+
+
+
xrandr --output VGA1 --auto --left-of LVDS1
+
+

This command makes xrandr try to find the native resolution of the device +connected to VGA1 and configures it to the left of your internal flat panel. +When running "xrandr" again, the output looks like this:

+
+
+
$ xrandr
+Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 8192 x 8192
+VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
+   1280x1024      60.0*+   75.0
+   1280x960       60.0
+   1152x864       75.0
+   1024x768       75.1     70.1     60.0
+   832x624        74.6
+   800x600        72.2     75.0     60.3     56.2
+   640x480        72.8     75.0     66.7     60.0
+   720x400        70.1
+LVDS1 connected 1280x800+1280+0 (normal left inverted right x axis y axis) 261mm x 163mm
+   1280x800       60.0*+   50.0
+   1024x768       85.0     75.0     70.1     60.0
+   832x624        74.6
+   800x600        85.1     72.2     75.0     60.3     56.2
+   640x480        85.0     72.8     75.0     59.9
+   720x400        85.0
+   640x400        85.1
+   640x350        85.1
+
+

Please note that i3 uses exactly the same API as xrandr does, so it will see +only what you can see in xrandr.

+

See also [presentations] for more examples of multi-monitor setups.

+
+
+

6.2. Interesting configuration for multi-monitor environments

+

There are several things to configure in i3 which may be interesting if you +have more than one monitor:

+
    +
  1. +

    +You can specify which workspace should be put on which screen. This + allows you to have a different set of workspaces when starting than just + 1 for the first monitor, 2 for the second and so on. See + [workspace_screen]. +

    +
    2. +
  2. +

    +If you want some applications to generally open on the bigger screen + (MPlayer, Firefox, …), you can assign them to a specific workspace, see + [assign_workspace]. +

    +
    3. +
  3. +

    +If you have many workspaces on many monitors, it might get hard to keep + track of which window you put where. Thus, you can use vim-like marks to + quickly switch between windows. See [vim_like_marks]. +

    +
    4. +
+
+
+
+
+

7. i3 and the rest of your software world

+
+
+

7.1. Displaying a status line

+

A very common thing amongst users of exotic window managers is a status line at +some corner of the screen. It is an often superior replacement to the widget +approach you have in the task bar of a traditional desktop environment.

+

If you don’t already have your favorite way of generating such a status line +(self-written scripts, conky, …), then i3status is the recommended tool for +this task. It was written in C with the goal of using as few syscalls as +possible to reduce the time your CPU is woken up from sleep states. Because +i3status only spits out text, you need to combine it with some other tool, like +i3bar. Use a pipe to connect them: i3status | i3bar -d.

+

Regardless of which application you use to display the status line, you +want to make sure that it registers as a dock window using EWMH hints. i3 will +position the window either at the top or at the bottom of the screen, depending +on which hint the application sets. With i3bar, you can use -d or -dbottom +for positioning it at the bottom and -dtop to position it at the top of the +screen.

+
+
+

7.2. Giving presentations (multi-monitor)

+

When giving a presentation, you typically want the audience to see what you see +on your screen and then go through a series of slides (if the presentation is +simple). For more complex presentations, you might want to have some notes +which only you can see on your screen, while the audience can only see the +slides.

+
+

7.2.1. Case 1: everybody gets the same output

+

This is the simple case. You connect your computer to the video projector, +turn on both (computer and video projector) and configure your X server to +clone the internal flat panel of your computer to the video output:

+
+
+
xrandr --output VGA1 --mode 1024x768 --same-as LVDS1
+
+

i3 will then use the lowest common subset of screen resolutions, the rest of +your screen will be left untouched (it will show the X background). So, in +our example, this would be 1024x768 (my notebook has 1280x800).

+
+
+

7.2.2. Case 2: you can see more than your audience

+

This case is a bit harder. First of all, you should configure the VGA output +somewhere near your internal flat panel, say right of it:

+
+
+
xrandr --output VGA1 --mode 1024x768 --right-of LVDS1
+
+

Now, i3 will put a new workspace (depending on your settings) on the new screen +and you are in multi-monitor mode (see [multi_monitor]).

+

Because i3 is not a compositing window manager, there is no ability to +display a window on two screens at the same time. Instead, your presentation +software needs to do this job (that is, open a window on each screen).

+
+
+
+
+
+
+ + + diff --git a/docs/4.0/wsbar.html b/docs/4.0/wsbar.html new file mode 100644 index 0000000..7a3b822 --- /dev/null +++ b/docs/4.0/wsbar.html @@ -0,0 +1,147 @@ + + + + + + +i3: External workspace bars + + + + + + + +
+

i3 - improved tiling WM

 + +
+
+ +
+
+

This document describes why the internal workspace bar is minimal and how an +external workspace bar can be used. It explains the concepts using i3-wsbar +as the reference implementation.

+
+
+
+

1. Internal and external bars

+
+

The internal workspace bar of i3 is meant to be a reasonable default so that +you can use i3 without having too much hassle when setting it up. It is quite +simple and intended to stay this way. So, there is no way to display your own +information in this bar (unlike dwm, wmii, awesome, …).

+

We chose not to implement such a mechanism because that would be duplicating +already existing functionality of tools such as dzen2, xmobar and similar. +Instead, you should disable the internal bar and use an external workspace bar +(which communicates with i3 through its IPC interface).

+
+
+
+

2. dock mode

+
+

You typically want to see the same workspace bar on every workspace on a +specific screen. Also, you don’t want to place the workspace bar somewhere +in your layout by hand. This is where dock mode comes in: When a program sets +the appropriate hint (_NET_WM_WINDOW_TYPE_DOCK), it will be managed in dock +mode by i3. That means it will be placed at the bottom of the screen (while +other edges of the screen are possible in the NetWM standard, this is not yet +implemented in i3), it will not overlap any other window and it will be on +every workspace for the specific screen it was placed on initially.

+
+
+
+

3. The IPC interface

+
+

In the context of using an external workspace bar, the IPC interface needs to +provide the bar program with the current workspaces and output (as in VGA-1, +LVDS-1, …) configuration. In the other direction, the program has to be able +to switch to specific workspaces.

+

By default, the IPC interface is enabled and places its UNIX socket in +~/.i3/ipc.sock.

+

To learn more about the protocol which is used for IPC, see docs/ipc.

+
+
+
+

4. Output changes (on-the-fly)

+
+

i3 implements the RandR API and can handle changing outputs quite well. So, an +external workspace bar implementation needs to make sure that when you change +the resolution of any of your screens (or enable/disable an output), the bars +will be adjusted properly.

+
+
+
+

5. i3-wsbar, the reference implementation

+
+

Please keep in mind that i3-wsbar is just a reference implementation. It is +shipped with i3 to have a reasonable default. Thus, i3-wsbar is designed to +work well with dzen2 and there are no plans to make it more generic.

+
+

5.1. The big picture

+

The most common reason to use an external workspace bar is to integrate system +information such as what i3status provides into the workspace bar (to save +screen space). So, we have i3status or a similar program, which only provides +text output (formatted in some way). To display this text nicely on the screen, +there are programs such as dzen2, xmobar and similar. We will stick to dzen2 +from here on. So, we have the output of i3status, which needs to go into dzen2 +somehow. But we also want to display the list of workspaces. i3-wsbar takes +input on stdin, combines it with a formatted workspace list and pipes it to +dzen2.

+

Please note that i3-wsbar does not print its output to stdout. Instead, it +launches the dzen2 instances on its own. This is necessary to handle changes +in the available outputs (to place a new dzen2 on a new screen for example).

+

+ +Overview + +

+
+
+

5.2. Running i3-wsbar

+

The most simple usage of i3-wsbar looks like this:

+
+
+
i3-wsbar -c "dzen2 -x %x -dock"
+
+

The %x in the command name will be replaced by the X position of the output +for which this workspace bar is running. i3 will automatically place the +workspace bar on the correct output when dzen2 is started in dock mode. The +bar which you will see should look exactly like the internal bar of i3.

+

To actually get a benefit, you want to give i3-wsbar some input:

+
+
+
i3status | i3-wsbar -c "dzen2 -x %x -dock"
+
+

It is recommended to place the above command in your i3 configuration file +to start it automatically with i3.

+
+
+
+
+
+ + + diff --git a/docs/4.0/wsbar.png b/docs/4.0/wsbar.png new file mode 100644 index 0000000..0789dec Binary files /dev/null and b/docs/4.0/wsbar.png differ diff --git a/docs/4.0/wsbar.svg b/docs/4.0/wsbar.svg new file mode 100644 index 0000000..e0c8679 --- /dev/null +++ b/docs/4.0/wsbar.svg @@ -0,0 +1,274 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/index.html.mako b/docs/index.html.mako index 927ca16..1c890bc 100644 --- a/docs/index.html.mako +++ b/docs/index.html.mako @@ -11,31 +11,47 @@ below will hopefully answer all your questions. If you have any corrections or suggestions please let us know!

+

+Because version 4.0 is quite new, we still have the old documentation for 3.ε +online for a few weeks. You can chose which version you want by clicking on the +boxes right next to the links. +

+

For users

-User’s Guide
+User’s Guide +4.0 +3.ε
Introduction and reference. Read this one.

-Multi-monitor
-Interesting for users of the nVidia binary driver. +Multi-monitor +4.0 +3.ε
+Interesting for users of the nVidia driver.

-Debugging i3
+Debugging i3 +4.0 +3.ε
Explains you how to enable the i3 logfile.

-External workspace bars
+External workspace bars +4.0 +3.ε
About bar programs such as i3bar or dzen2.

-i3 reference card (PDF)
+i3 reference card (PDF) +4.0 +3.ε
Might be useful to memorize i3’s shortcuts.

@@ -49,17 +65,23 @@ Tells you how to check out our git repository.

-Hacking Howto
+Hacking Howto +4.0 +3.ε
Helps you if you want to get into i3’s source code.

-Debugging i3
+Debugging i3 +4.0 +3.ε
Explains you how to enable core dumps.

-IPC documentation
+IPC documentation +4.0 +3.ε
Explains how i3’s Inter Process Communication interface works. Read this if you want to talk to i3 within your own scripts or programs.