s/separate/seperate/g (Thanks Donald)
This commit is contained in:
parent
a8c4d255cf
commit
2959dcb24c
|
@ -14,7 +14,7 @@ debugging and/or need further help, do not hesitate to contact us!
|
|||
|
||||
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
|
||||
stderr in xsession. While you’re at it, putting each run of i3 in a seperate
|
||||
log file with date/time in it is a good idea to not get confused about the
|
||||
different log files later on.
|
||||
|
||||
|
|
|
@ -216,7 +216,7 @@ screen you are currently on.
|
|||
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
|
||||
seperate of each other. Other window managers also call this ``Virtual
|
||||
desktops''.
|
||||
|
||||
=== The layout table
|
||||
|
@ -264,7 +264,7 @@ should be chosen for those:
|
|||
== Startup (src/mainx.c, main())
|
||||
|
||||
* Establish the xcb connection
|
||||
* Check for XKB extension on the separate X connection
|
||||
* Check for XKB extension on the seperate X connection
|
||||
* Check for Xinerama screens
|
||||
* Grab the keycodes for which bindings exist
|
||||
* Manage all existing windows
|
||||
|
|
4
docs/ipc
4
docs/ipc
|
@ -3,7 +3,7 @@ IPC interface (interprocess communication)
|
|||
Michael Stapelberg <michael+i3@stapelberg.de>
|
||||
March 2010
|
||||
|
||||
This document describes how to interface with i3 from a separate process. This
|
||||
This document describes how to interface with i3 from a seperate 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.
|
||||
|
@ -241,7 +241,7 @@ 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.
|
||||
seperate connection to receive events.
|
||||
|
||||
=== Subscribing to events
|
||||
|
||||
|
|
|
@ -556,7 +556,7 @@ 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
|
||||
turn off the internal bar completely, so that you can use a seperate program to
|
||||
display it (see +i3-wsbar+, a sample implementation of such a program):
|
||||
|
||||
*Syntax*:
|
||||
|
|
Loading…
Reference in New Issue