X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fipc.html;h=268e1405341efda25643ad502376660c0a19c267;hb=6c4bce4e72f0b8cf1aa9aa5fa625026831ed732a;hp=350483e33f37c8463906ac6da522aa4867504de3;hpb=d049fd68707996f65f358367c43fdde2b9d7e2b8;p=i3%2Fi3.github.io diff --git a/docs/ipc.html b/docs/ipc.html index 350483e..268e140 100644 --- a/docs/ipc.html +++ b/docs/ipc.html @@ -4,7 +4,7 @@ - + i3: IPC interface (interprocess communication) @@ -33,9 +33,9 @@ document.addEventListener("DOMContentLoaded", function(){asciidoc.footnotes(); a Michael Stapelberg
<michael@i3wm.org>
September 2017 -
-
Table of Contents
- +
+
Table of Contents
+
@@ -177,6 +177,12 @@ cellspacing="0" cellpadding="4">

TICK

Sends a tick event with the specified payload.

+ +

11

+

SYNC

+

SYNC

+

Sends an i3 sync event with the specified random value to the specified window.

+
@@ -656,6 +662,14 @@ window (integer)

+window_properties (map) +
+
+

+ X11 window properties title, instance, class, window_role and transient_for. +

+
+
urgent (bool)
@@ -826,6 +840,12 @@ VGA1 "width": 1280, "height": 782 }, + "window_properties": { + "class": "Evince", + "instance": "evince", + "title": "Properties", + "transient_for": 52428808 + }, "floating_nodes": [], "nodes": [ @@ -1213,6 +1233,17 @@ events generated prior to the SEND_TICK message (happened-before relati 
{ "success": true }
+
+

3.13. SYNC reply

+

The reply is a map containing the "success" member. After the reply was +received, the i3 sync message was +responded to.

+

Example:

+
+
+
{ "success": true }
+
+
@@ -1230,6 +1261,13 @@ situation can happen: You send a GET_WORKSPACES request but you receive a 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.

+

If an event message needs to be sent and the socket is not writeable (write +returns EAGAIN, happens when the socket doesn’t have enough buffer space for +writing new data) then i3 uses a queue system to store outgoing messages for +each client. This is combined with a timer: if the message queue for a client is +not empty and no data where successfully written in the past 10 seconds, the +connection is killed. Practically, this means that your client should try to +always read events from the socket to avoid having its connection closed.

4.1. Subscribing to events

By sending a message of type SUBSCRIBE with a JSON-encoded array as payload @@ -1850,7 +1888,9 @@ From here on out, send/receive all messages using the detected byte order.