koma/i3
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: merge spelling and grammar fixes by sasha (Thanks!)

Browse Source
This commit is contained in:
Michael Stapelberg
2010-03-21 01:50:10 +01:00
parent 77efb29d9f
commit 234ed6c99b
13 changed files with 215 additions and 193 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/ipc
View File

@ -28,10 +28,10 @@ my $sock = IO::Socket::UNIX->new(Peer => '/tmp/i3-ipc.sock');
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). Afterwards follows
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 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
@ -75,11 +75,11 @@ sub format_ipc_command {
}
$sock->write(format_ipc_command("exit"));
------------------------------------------------------------
------------------------------------------------------------------------------
== Receiving replies from i3
Replies of i3 usually consist of a simple string (the length of the string
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
@ -240,8 +240,8 @@ 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 advise to create a separate
connection to receive events.
event based library may not have a problem here), I suggest you create a
separate connection to receive events.
=== Subscribing to events