nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

s/separate/seperate/g (Thanks Donald)

This commit is contained in:
Michael Stapelberg 2010-12-25 15:42:53 +01:00
parent a8c4d255cf
commit 2959dcb24c
4 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/debugging
View File

@ -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.

4
docs/hacking-howto
View File

@ -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
View File

@ -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

2
docs/userguide
View File

@ -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*: