X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fipc;h=f25d7a7447737d4734361a7880fc991ed553ffc2;hb=b6485c98a299e86cc7c131f02d56ae4a71337724;hp=f011e773c42b9b4a1218061df1ee6c9b2e5311ca;hpb=8a805cdd5cbf6c3564d88ea47a531a1abfd6bcc0;p=i3%2Fi3

diff --git a/docs/ipc b/docs/ipc
index f011e773..f25d7a74 100644
--- a/docs/ipc
+++ b/docs/ipc
@@ -328,6 +328,8 @@ window (integer)::
 	This field is set to null for split containers or otherwise empty
 	containers. This ID corresponds to what xwininfo(1) and other
 	X11-related tools display (usually in hex).
+window_properties (map)::
+	X11 window properties title, instance, class, window_role and transient_for.
 urgent (bool)::
 	Whether this container (window, split container, floating container or
 	workspace) has the urgency hint set, directly or indirectly. All parent
@@ -423,6 +425,12 @@ JSON dump:
 	    "width": 1280,
 	    "height": 782
 	  },
+	  "window_properties": {
+	    "class": "Evince",
+	    "instance": "evince",
+	    "title": "Properties",
+	    "transient_for": 52428808
+	  },
 	  "floating_nodes": [],
 	  "nodes": [
 
@@ -673,9 +681,11 @@ responded to.
 
 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.
+(like I3_IPC_EVENT_WORKSPACE). Events sent by i3 follow a format similar to
+replies but with the highest bit of the message type set to 1 to indicate an
+event reply instead of a normal reply. Note that event types and reply types
+do not follow the same enumeration scheme (e.g. event type 0 corresponds to the
+workspace event however reply type 0 corresponds to the COMMAND 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
@@ -685,6 +695,14 @@ 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.
+
 === Subscribing to events
 
 By sending a message of type SUBSCRIBE with a JSON-encoded array as payload
@@ -932,6 +950,7 @@ C::
 	* i3 includes a headerfile +i3/ipc.h+ which provides you all constants.
 	* https://github.com/acrisci/i3ipc-glib
 C++::
+	* https://github.com/Iskustvo/i3-ipcpp[i3-ipc++]
 	* https://github.com/drmgc/i3ipcpp
 Go::
 	* https://github.com/mdirkse/i3ipc-go