git.sur5r.net Git - i3/i3/blob - docs/ipc

   1 IPC interface (interprocess communication)
   2 ==========================================
   3 Michael Stapelberg <michael@i3wm.org>
   4 October 2012
   5
   6 This document describes how to interface with i3 from a separate process. This
   7 is useful for example to remote-control i3 (to write test cases for example) or
   8 to get various information like the current workspaces to implement an external
   9 workspace bar.
  10
  11 The method of choice for IPC in our case is a unix socket because it has very
  12 little overhead on both sides and is usually available without headaches in
  13 most languages. In the default configuration file, the ipc-socket gets created
  14 in +/tmp/i3-%u.XXXXXX/ipc-socket.%p+ where +%u+ is your UNIX username, +%p+ is
  15 the PID of i3 and XXXXXX is a string of random characters from the portable
  16 filename character set (see mkdtemp(3)). You can get the socketpath from i3 by
  17 calling +i3 --get-socketpath+.
  18
  19 All i3 utilities, like +i3-msg+ and +i3-input+ will read the +I3_SOCKET_PATH+
  20 X11 property, stored on the X11 root window.
  21
  22 [WARNING]
  23 .Use an existing library!
  24 There are existing libraries for many languages. You can have a look at
  25 <<libraries>> or search the web if your language of choice is not mentioned.
  26 Usually, it is not necessary to implement low-level communication with i3
  27 directly.
  28
  29 == Establishing a connection
  30
  31 To establish a connection, simply open the IPC socket. The following code
  32 snippet illustrates this in Perl:
  33
  34 -------------------------------------------------------------
  35 use IO::Socket::UNIX;
  36 chomp(my $path = qx(i3 --get-socketpath));
  37 my $sock = IO::Socket::UNIX->new(Peer => $path);
  38 -------------------------------------------------------------
  39
  40 == Sending messages to i3
  41
  42 To send a message to i3, you have to format in the binary message format which
  43 i3 expects. This format specifies a magic string in the beginning to ensure
  44 the integrity of messages (to prevent follow-up errors). Following the magic
  45 string comes the length of the payload of the message as 32-bit integer, and
  46 the type of the message as 32-bit integer (the integers are not converted, so
  47 they are in native byte order).
  48
  49 The magic string currently is "i3-ipc" and will only be changed when a change
  50 in the IPC API is done which breaks compatibility (we hope that we don’t need
  51 to do that).
  52
  53 Currently implemented message types are the following:
  54
  55 COMMAND (0)::
  56         The payload of the message is a command for i3 (like the commands you
  57         can bind to keys in the configuration file) and will be executed
  58         directly after receiving it.
  59 GET_WORKSPACES (1)::
  60         Gets the current workspaces. The reply will be a JSON-encoded list of
  61         workspaces (see the reply section).
  62 SUBSCRIBE (2)::
  63         Subscribes your connection to certain events. See <<events>> for a
  64         description of this message and the concept of events.
  65 GET_OUTPUTS (3)::
  66         Gets the current outputs. The reply will be a JSON-encoded list of outputs
  67         (see the reply section).
  68 GET_TREE (4)::
  69         Gets the layout tree. i3 uses a tree as data structure which includes
  70         every container. The reply will be the JSON-encoded tree (see the reply
  71         section).
  72 GET_MARKS (5)::
  73         Gets a list of marks (identifiers for containers to easily jump to them
  74         later). The reply will be a JSON-encoded list of window marks (see
  75         reply section).
  76 GET_BAR_CONFIG (6)::
  77         Gets the configuration (as JSON map) of the workspace bar with the
  78         given ID. If no ID is provided, an array with all configured bar IDs is
  79         returned instead.
  80 GET_VERSION (7)::
  81         Gets the version of i3. The reply will be a JSON-encoded dictionary
  82         with the major, minor, patch and human-readable version.
  83
  84 So, a typical message could look like this:
  85 --------------------------------------------------
  86 "i3-ipc" <message length> <message type> <payload>
  87 --------------------------------------------------
  88
  89 Or, as a hexdump:
  90 ------------------------------------------------------------------------------
  91 00000000  69 33 2d 69 70 63 04 00  00 00 00 00 00 00 65 78  |i3-ipc........ex|
  92 00000010  69 74                                             |it|
  93 ------------------------------------------------------------------------------
  94
  95 To generate and send such a message, you could use the following code in Perl:
  96 ------------------------------------------------------------
  97 sub format_ipc_command {
  98     my ($msg) = @_;
  99     my $len;
 100     # Get the real byte count (vs. amount of characters)
 101     { use bytes; $len = length($msg); }
 102     return "i3-ipc" . pack("LL", $len, 0) . $msg;
 103 }
 104
 105 $sock->write(format_ipc_command("exit"));
 106 ------------------------------------------------------------------------------
 107
 108 == Receiving replies from i3
 109
 110 Replies from i3 usually consist of a simple string (the length of the string
 111 is the message_length, so you can consider them length-prefixed) which in turn
 112 contain the JSON serialization of a data structure. For example, the
 113 GET_WORKSPACES message returns an array of workspaces (each workspace is a map
 114 with certain attributes).
 115
 116 === Reply format
 117
 118 The reply format is identical to the normal message format. There also is
 119 the magic string, then the message length, then the message type and the
 120 payload.
 121
 122 The following reply types are implemented:
 123
 124 COMMAND (0)::
 125         Confirmation/Error code for the COMMAND message.
 126 WORKSPACES (1)::
 127         Reply to the GET_WORKSPACES message.
 128 SUBSCRIBE (2)::
 129         Confirmation/Error code for the SUBSCRIBE message.
 130 OUTPUTS (3)::
 131         Reply to the GET_OUTPUTS message.
 132 TREE (4)::
 133         Reply to the GET_TREE message.
 134 MARKS (5)::
 135         Reply to the GET_MARKS message.
 136 BAR_CONFIG (6)::
 137         Reply to the GET_BAR_CONFIG message.
 138 VERSION (7)::
 139         Reply to the GET_VERSION message.
 140
 141 === COMMAND reply
 142
 143 The reply consists of a single serialized map. At the moment, the only
 144 property is +success (bool)+, but this will be expanded in future versions.
 145
 146 *Example:*
 147 -------------------
 148 { "success": true }
 149 -------------------
 150
 151 === WORKSPACES reply
 152
 153 The reply consists of a serialized list of workspaces. Each workspace has the
 154 following properties:
 155
 156 num (integer)::
 157         The logical number of the workspace. Corresponds to the command
 158         to switch to this workspace.
 159 name (string)::
 160         The name of this workspace (by default num+1), as changed by the
 161         user. Encoded in UTF-8.
 162 visible (boolean)::
 163         Whether this workspace is currently visible on an output (multiple
 164         workspaces can be visible at the same time).
 165 focused (boolean)::
 166         Whether this workspace currently has the focus (only one workspace
 167         can have the focus at the same time).
 168 urgent (boolean)::
 169         Whether a window on this workspace has the "urgent" flag set.
 170 rect (map)::
 171         The rectangle of this workspace (equals the rect of the output it
 172         is on), consists of x, y, width, height.
 173 output (string)::
 174         The video output this workspace is on (LVDS1, VGA1, …).
 175
 176 *Example:*
 177 -------------------
 178 [
 179  {
 180   "num": 0,
 181   "name": "1",
 182   "visible": true,
 183   "focused": true,
 184   "urgent": false,
 185   "rect": {
 186    "x": 0,
 187    "y": 0,
 188    "width": 1280,
 189    "height": 800
 190   },
 191   "output": "LVDS1"
 192  },
 193  {
 194   "num": 1,
 195   "name": "2",
 196   "visible": false,
 197   "focused": false,
 198   "urgent": false,
 199   "rect": {
 200    "x": 0,
 201    "y": 0,
 202    "width": 1280,
 203    "height": 800
 204   },
 205   "output": "LVDS1"
 206  }
 207 ]
 208 -------------------
 209
 210 === SUBSCRIBE reply
 211
 212 The reply consists of a single serialized map. The only property is
 213 +success (bool)+, indicating whether the subscription was successful (the
 214 default) or whether a JSON parse error occurred.
 215
 216 *Example:*
 217 -------------------
 218 { "success": true }
 219 -------------------
 220
 221 === OUTPUTS reply
 222
 223 The reply consists of a serialized list of outputs. Each output has the
 224 following properties:
 225
 226 name (string)::
 227         The name of this output (as seen in +xrandr(1)+). Encoded in UTF-8.
 228 active (boolean)::
 229         Whether this output is currently active (has a valid mode).
 230 current_workspace (integer)::
 231         The current workspace which is visible on this output. +null+ if the
 232         output is not active.
 233 rect (map)::
 234         The rectangle of this output (equals the rect of the output it
 235         is on), consists of x, y, width, height.
 236
 237 *Example:*
 238 -------------------
 239 [
 240  {
 241   "name": "LVDS1",
 242   "active": true,
 243   "current_workspace": 4,
 244   "rect": {
 245    "x": 0,
 246    "y": 0,
 247    "width": 1280,
 248    "height": 800
 249   }
 250  },
 251  {
 252   "name": "VGA1",
 253   "active": true,
 254   "current_workspace": 1,
 255   "rect": {
 256    "x": 1280,
 257    "y": 0,
 258    "width": 1280,
 259    "height": 1024
 260   },
 261  }
 262 ]
 263 -------------------
 264
 265 === TREE reply
 266
 267 The reply consists of a serialized tree. Each node in the tree (representing
 268 one container) has at least the properties listed below. While the nodes might
 269 have more properties, please do not use any properties which are not documented
 270 here. They are not yet finalized and will probably change!
 271
 272 id (integer)::
 273         The internal ID (actually a C pointer value) of this container. Do not
 274         make any assumptions about it. You can use it to (re-)identify and
 275         address containers when talking to i3.
 276 name (string)::
 277         The internal name of this container. For all containers which are part
 278         of the tree structure down to the workspace contents, this is set to a
 279         nice human-readable name of the container.
 280         For all other containers, the content is not defined (yet).
 281 border (string)::
 282         Can be either "normal", "none" or "1pixel", dependending on the
 283         container’s border style.
 284 current_border_width (integer)::
 285         Number of pixels of the border width.
 286 layout (string)::
 287         Can be either "splith", "splitv", "stacked", "tabbed", "dockarea" or
 288         "output".
 289         Other values might be possible in the future, should we add new
 290         layouts.
 291 orientation (string)::
 292         Can be either "none" (for non-split containers), "horizontal" or
 293         "vertical".
 294         THIS FIELD IS OBSOLETE. It is still present, but your code should not
 295         use it. Instead, rely on the layout field.
 296 percent (float)::
 297         The percentage which this container takes in its parent. A value of
 298         +null+ means that the percent property does not make sense for this
 299         container, for example for the root container.
 300 rect (map)::
 301         The absolute display coordinates for this container. Display
 302         coordinates means that when you have two 1600x1200 monitors on a single
 303         X11 Display (the standard way), the coordinates of the first window on
 304         the second monitor are +{ "x": 1600, "y": 0, "width": 1600, "height":
 305         1200 }+.
 306 window_rect (map)::
 307         The coordinates of the *actual client window* inside its container.
 308         These coordinates are relative to the container and do not include the
 309         window decoration (which is actually rendered on the parent container).
 310         So, when using the +default+ layout, you will have a 2 pixel border on
 311         each side, making the window_rect +{ "x": 2, "y": 0, "width": 632,
 312         "height": 366 }+ (for example).
 313 geometry (map)::
 314         The original geometry the window specified when i3 mapped it. Used when
 315         switching a window to floating mode, for example.
 316 window (integer)::
 317         The X11 window ID of the *actual client window* inside this container.
 318         This field is set to null for split containers or otherwise empty
 319         containers. This ID corresponds to what xwininfo(1) and other
 320         X11-related tools display (usually in hex).
 321 urgent (bool)::
 322         Whether this container (window or workspace) has the urgency hint set.
 323 focused (bool)::
 324         Whether this container is currently focused.
 325
 326 Please note that in the following example, I have left out some keys/values
 327 which are not relevant for the type of the node. Otherwise, the example would
 328 be by far too long (it already is quite long, despite showing only 1 window and
 329 one dock window).
 330
 331 It is useful to have an overview of the structure before taking a look at the
 332 JSON dump:
 333
 334 * root
 335 ** LVDS1
 336 *** topdock
 337 *** content
 338 **** workspace 1
 339 ***** window 1
 340 *** bottomdock
 341 **** dock window 1
 342 ** VGA1
 343
 344 *Example:*
 345 -----------------------
 346 {
 347  "id": 6875648,
 348  "name": "root",
 349  "rect": {
 350    "x": 0,
 351    "y": 0,
 352    "width": 1280,
 353    "height": 800
 354  },
 355  "nodes": [
 356
 357    {
 358     "id": 6878320,
 359     "name": "LVDS1",
 360     "layout": "output",
 361     "rect": {
 362       "x": 0,
 363       "y": 0,
 364       "width": 1280,
 365       "height": 800
 366     },
 367     "nodes": [
 368
 369       {
 370        "id": 6878784,
 371        "name": "topdock",
 372        "layout": "dockarea",
 373        "orientation": "vertical",
 374        "rect": {
 375          "x": 0,
 376          "y": 0,
 377          "width": 1280,
 378          "height": 0
 379        },
 380       },
 381
 382       {
 383        "id": 6879344,
 384        "name": "content",
 385        "rect": {
 386          "x": 0,
 387          "y": 0,
 388          "width": 1280,
 389          "height": 782
 390        },
 391        "nodes": [
 392
 393          {
 394           "id": 6880464,
 395           "name": "1",
 396           "orientation": "horizontal",
 397           "rect": {
 398             "x": 0,
 399             "y": 0,
 400             "width": 1280,
 401             "height": 782
 402           },
 403           "floating_nodes": [],
 404           "nodes": [
 405
 406             {
 407              "id": 6929968,
 408              "name": "#aa0000",
 409              "border": "normal",
 410              "percent": 1,
 411              "rect": {
 412                "x": 0,
 413                "y": 18,
 414                "width": 1280,
 415                "height": 782
 416              }
 417             }
 418
 419           ]
 420          }
 421
 422        ]
 423       },
 424
 425       {
 426        "id": 6880208,
 427        "name": "bottomdock",
 428        "layout": "dockarea",
 429        "orientation": "vertical",
 430        "rect": {
 431          "x": 0,
 432          "y": 782,
 433          "width": 1280,
 434          "height": 18
 435        },
 436        "nodes": [
 437
 438          {
 439           "id": 6931312,
 440           "name": "#00aa00",
 441           "percent": 1,
 442           "rect": {
 443             "x": 0,
 444             "y": 782,
 445             "width": 1280,
 446             "height": 18
 447           }
 448          }
 449
 450        ]
 451       }
 452     ]
 453    }
 454  ]
 455 }
 456 ------------------------
 457
 458 === MARKS reply
 459
 460 The reply consists of a single array of strings for each container that has a
 461 mark. The order of that array is undefined. If more than one container has the
 462 same mark, it will be represented multiple times in the reply (the array
 463 contents are not unique).
 464
 465 If no window has a mark the response will be the empty array [].
 466
 467 === BAR_CONFIG reply
 468
 469 This can be used by third-party workspace bars (especially i3bar, but others
 470 are free to implement compatible alternatives) to get the +bar+ block
 471 configuration from i3.
 472
 473 Depending on the input, the reply is either:
 474
 475 empty input::
 476         An array of configured bar IDs
 477 Bar ID::
 478         A JSON map containing the configuration for the specified bar.
 479
 480 Each bar configuration has the following properties:
 481
 482 id (string)::
 483         The ID for this bar. Included in case you request multiple
 484         configurations and want to differentiate the different replies.
 485 mode (string)::
 486         Either +dock+ (the bar sets the dock window type) or +hide+ (the bar
 487         does not show unless a specific key is pressed).
 488 position (string)::
 489         Either +bottom+ or +top+ at the moment.
 490 status_command (string)::
 491         Command which will be run to generate a statusline. Each line on stdout
 492         of this command will be displayed in the bar. At the moment, no
 493         formatting is supported.
 494 font (string)::
 495         The font to use for text on the bar.
 496 workspace_buttons (boolean)::
 497         Display workspace buttons or not? Defaults to true.
 498 verbose (boolean)::
 499         Should the bar enable verbose output for debugging? Defaults to false.
 500 colors (map)::
 501         Contains key/value pairs of colors. Each value is a color code in hex,
 502         formatted #rrggbb (like in HTML).
 503
 504 The following colors can be configured at the moment:
 505
 506 background::
 507         Background color of the bar.
 508 statusline::
 509         Text color to be used for the statusline.
 510 separator::
 511         Text color to be used for the separator.
 512 focused_workspace_text/focused_workspace_bg::
 513         Text color/background color for a workspace button when the workspace
 514         has focus.
 515 active_workspace_text/active_workspace_bg::
 516         Text color/background color for a workspace button when the workspace
 517         is active (visible) on some output, but the focus is on another one.
 518         You can only tell this apart from the focused workspace when you are
 519         using multiple monitors.
 520 inactive_workspace_text/inactive_workspace_bg::
 521         Text color/background color for a workspace button when the workspace
 522         does not have focus and is not active (visible) on any output. This
 523         will be the case for most workspaces.
 524 urgent_workspace_text/urgent_workspace_bar::
 525         Text color/background color for workspaces which contain at least one
 526         window with the urgency hint set.
 527
 528
 529 *Example of configured bars:*
 530 --------------
 531 ["bar-bxuqzf"]
 532 --------------
 533
 534 *Example of bar configuration:*
 535 --------------
 536 {
 537  "id": "bar-bxuqzf",
 538  "mode": "dock",
 539  "position": "bottom",
 540  "status_command": "i3status",
 541  "font": "-misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1",
 542  "workspace_buttons": true,
 543  "verbose": false,
 544  "colors": {
 545    "background": "#c0c0c0",
 546    "statusline": "#00ff00",
 547    "focused_workspace_text": "#ffffff",
 548    "focused_workspace_bg": "#000000"
 549  }
 550 }
 551 --------------
 552
 553 === VERSION reply
 554
 555 The reply consists of a single JSON dictionary with the following keys:
 556
 557 major (integer)::
 558         The major version of i3, such as +4+.
 559 minor (integer)::
 560         The minor version of i3, such as +2+. Changes in the IPC interface (new
 561         features) will only occur with new minor (or major) releases. However,
 562         bugfixes might be introduced in patch releases, too.
 563 patch (integer)::
 564         The patch version of i3, such as +1+ (when the complete version is
 565         +4.2.1+). For versions such as +4.2+, patch will be set to +0+.
 566 human_readable (string)::
 567         A human-readable version of i3 containing the precise git version,
 568         build date and branch name. When you need to display the i3 version to
 569         your users, use the human-readable version whenever possible (since
 570         this is what +i3 --version+ displays, too).
 571
 572 *Example:*
 573 -------------------
 574 {
 575    "human_readable" : "4.2-169-gf80b877 (2012-08-05, branch \"next\")",
 576    "minor" : 2,
 577    "patch" : 0,
 578    "major" : 4
 579 }
 580 -------------------
 581
 582 == Events
 583
 584 [[events]]
 585
 586 To get informed when certain things happen in i3, clients can subscribe to
 587 events. Events consist of a name (like "workspace") and an event reply type
 588 (like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format
 589 as replies to specific commands. However, the highest bit of the message type
 590 is set to 1 to indicate that this is an event reply instead of a normal reply.
 591
 592 Caveat: As soon as you subscribe to an event, it is not guaranteed any longer
 593 that the requests to i3 are processed in order. This means, the following
 594 situation can happen: You send a GET_WORKSPACES request but you receive a
 595 "workspace" event before receiving the reply to GET_WORKSPACES. If your
 596 program does not want to cope which such kinds of race conditions (an
 597 event based library may not have a problem here), I suggest you create a
 598 separate connection to receive events.
 599
 600 === Subscribing to events
 601
 602 By sending a message of type SUBSCRIBE with a JSON-encoded array as payload
 603 you can register to an event.
 604
 605 *Example:*
 606 ---------------------------------
 607 type: SUBSCRIBE
 608 payload: [ "workspace", "focus" ]
 609 ---------------------------------
 610
 611
 612 === Available events
 613
 614 The numbers in parenthesis is the event type (keep in mind that you need to
 615 strip the highest bit first).
 616
 617 workspace (0)::
 618         Sent when the user switches to a different workspace, when a new
 619         workspace is initialized or when a workspace is removed (because the
 620         last client vanished).
 621 output (1)::
 622         Sent when RandR issues a change notification (of either screens,
 623         outputs, CRTCs or output properties).
 624 mode (2)::
 625         Sent whenever i3 changes its binding mode.
 626 window (3)::
 627         Sent when a client's window is successfully reparented (that is when i3
 628         has finished fitting it into a container).
 629 barconfig_update (4)::
 630     Sent when the hidden_state or mode field in the barconfig of any bar
 631     instance was updated.
 632
 633 *Example:*
 634 --------------------------------------------------------------------
 635 # the appropriate 4 bytes read from the socket are stored in $input
 636
 637 # unpack a 32-bit unsigned integer
 638 my $message_type = unpack("L", $input);
 639
 640 # check if the highest bit is 1
 641 my $is_event = (($message_type >> 31) == 1);
 642
 643 # use the other bits
 644 my $event_type = ($message_type & 0x7F);
 645
 646 if ($is_event) {
 647   say "Received event of type $event_type";
 648 }
 649 --------------------------------------------------------------------
 650
 651 === workspace event
 652
 653 This event consists of a single serialized map containing a property
 654 +change (string)+ which indicates the type of the change ("focus", "init",
 655 "empty", "urgent").
 656
 657 Moreover, when the change is "focus", an +old (object)+ and a +current
 658 (object)+ properties will be present with the previous and current
 659 workspace respectively.  When the first switch occurs (when i3 focuses
 660 the workspace visible at the beginning) there is no previous
 661 workspace, and the +old+ property will be set to +null+.  Also note
 662 that if the previous is empty it will get destroyed when switching,
 663 but will still be present in the "old" property.
 664
 665 *Example:*
 666 ---------------------
 667 {
 668  "change": "focus",
 669  "current": {
 670   "id": 28489712,
 671   "type":4,
 672   ...
 673  }
 674  "old": {
 675   "id": 28489715,
 676   "type": 4,
 677   ...
 678  }
 679 }
 680 ---------------------
 681
 682 === output event
 683
 684 This event consists of a single serialized map containing a property
 685 +change (string)+ which indicates the type of the change (currently only
 686 "unspecified").
 687
 688 *Example:*
 689 ---------------------------
 690 { "change": "unspecified" }
 691 ---------------------------
 692
 693 === mode event
 694
 695 This event consists of a single serialized map containing a property
 696 +change (string)+ which holds the name of current mode in use. The name
 697 is the same as specified in config when creating a mode. The default
 698 mode is simply named default.
 699
 700 *Example:*
 701 ---------------------------
 702 { "change": "default" }
 703 ---------------------------
 704
 705 === window event
 706
 707 This event consists of a single serialized map containing a property
 708 +change (string)+ which currently can indicate only that a new window
 709 has been successfully reparented (the value will be "new").
 710
 711 Additionally a +container (object)+ field will be present, which consists
 712 of the window's parent container. Be aware that the container will hold
 713 the initial name of the newly reparented window (e.g. if you run urxvt
 714 with a shell that changes the title, you will still at this point get the
 715 window title as "urxvt").
 716
 717 *Example:*
 718 ---------------------------
 719 {
 720  "change": "new",
 721  "container": {
 722   "id": 35569536,
 723   "type": 2,
 724   ...
 725  }
 726 }
 727 ---------------------------
 728
 729 === barconfig_update event
 730
 731 This event consists of a single serialized map reporting on options from the
 732 barconfig of the specified bar_id that were updated in i3. The map always
 733 consists of a property +id (string)+, which specifies to which bar instance the
 734 sent config update belongs, a property +hidden_state (string)+, which indicates
 735 the hidden_state of an i3bar instance, and a property +mode (string)+, which
 736 corresponds to the current mode.
 737
 738 *Example:*
 739 ---------------------------
 740 {
 741     "id": "bar-0",
 742     "hidden_state": "hide"
 743     "mode": "hide"
 744 }
 745 ---------------------------
 746
 747 == See also (existing libraries)
 748
 749 [[libraries]]
 750
 751 For some languages, libraries are available (so you don’t have to implement
 752 all this on your own). This list names some (if you wrote one, please let me
 753 know):
 754
 755 C::
 756         i3 includes a headerfile +i3/ipc.h+ which provides you all constants.
 757         However, there is no library yet.
 758 Ruby::
 759         http://github.com/badboy/i3-ipc
 760 Perl::
 761         https://metacpan.org/module/AnyEvent::I3
 762 Python::
 763         * https://github.com/whitelynx/i3ipc
 764         * https://github.com/ziberna/i3-py (includes higher-level features)
 765 Go::
 766         * https://github.com/proxypoke/i3ipc