X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fipc;h=f25d7a7447737d4734361a7880fc991ed553ffc2;hb=b6485c98a299e86cc7c131f02d56ae4a71337724;hp=8b767adebffa127bab432c2c9607b57ce491567b;hpb=f6f198c3fed90cfc4672588cf3d6a8c712f06f97;p=i3%2Fi3 diff --git a/docs/ipc b/docs/ipc index 8b767ade..f25d7a74 100644 --- a/docs/ipc +++ b/docs/ipc @@ -65,6 +65,7 @@ to do that). | 8 | +GET_BINDING_MODES+ | <<_binding_modes_reply,BINDING_MODES>> | Gets the names of all currently configured binding modes. | 9 | +GET_CONFIG+ | <<_config_reply,CONFIG>> | Returns the last loaded i3 config. | 10 | +SEND_TICK+ | <<_tick_reply,TICK>> | Sends a tick event with the specified payload. +| 11 | +SYNC+ | <<_sync_reply,SYNC>> | Sends an i3 sync event with the specified random value to the specified window. |====================================================== So, a typical message could look like this: @@ -327,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 @@ -422,6 +425,12 @@ JSON dump: "width": 1280, "height": 782 }, + "window_properties": { + "class": "Evince", + "instance": "evince", + "title": "Properties", + "transient_for": 52428808 + }, "floating_nodes": [], "nodes": [ @@ -654,15 +663,29 @@ events generated prior to the +SEND_TICK+ message (happened-before relation). { "success": true } ------------------- +[[_sync_reply]] +=== SYNC reply + +The reply is a map containing the "success" member. After the reply was +received, the https://i3wm.org/docs/testsuite.html#i3_sync[i3 sync message] was +responded to. + +*Example:* +------------------- +{ "success": true } +------------------- + == Events [[events]] 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 @@ -672,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 @@ -919,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