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

   1 IPC interface (interprocess communication)
   2 ==========================================
   3 Michael Stapelberg <michael@i3wm.org>
   4 February 2014
   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 containers that have an X11 window, the content is the title
 281         (_NET_WM_NAME property) of that window.
 282         For all other containers, the content is not defined (yet).
 283 type (string)::
 284         Type of this container. Can be one of "root", "output", "con",
 285         "floating_con", "workspace" or "dockarea".
 286 border (string)::
 287         Can be either "normal", "none" or "1pixel", dependending on the
 288         container’s border style.
 289 current_border_width (integer)::
 290         Number of pixels of the border width.
 291 layout (string)::
 292         Can be either "splith", "splitv", "stacked", "tabbed", "dockarea" or
 293         "output".
 294         Other values might be possible in the future, should we add new
 295         layouts.
 296 orientation (string)::
 297         Can be either "none" (for non-split containers), "horizontal" or
 298         "vertical".
 299         THIS FIELD IS OBSOLETE. It is still present, but your code should not
 300         use it. Instead, rely on the layout field.
 301 percent (float)::
 302         The percentage which this container takes in its parent. A value of
 303         +null+ means that the percent property does not make sense for this
 304         container, for example for the root container.
 305 rect (map)::
 306         The absolute display coordinates for this container. Display
 307         coordinates means that when you have two 1600x1200 monitors on a single
 308         X11 Display (the standard way), the coordinates of the first window on
 309         the second monitor are +{ "x": 1600, "y": 0, "width": 1600, "height":
 310         1200 }+.
 311 window_rect (map)::
 312         The coordinates of the *actual client window* inside its container.
 313         These coordinates are relative to the container and do not include the
 314         window decoration (which is actually rendered on the parent container).
 315         So, when using the +default+ layout, you will have a 2 pixel border on
 316         each side, making the window_rect +{ "x": 2, "y": 0, "width": 632,
 317         "height": 366 }+ (for example).
 318 geometry (map)::
 319         The original geometry the window specified when i3 mapped it. Used when
 320         switching a window to floating mode, for example.
 321 window (integer)::
 322         The X11 window ID of the *actual client window* inside this container.
 323         This field is set to null for split containers or otherwise empty
 324         containers. This ID corresponds to what xwininfo(1) and other
 325         X11-related tools display (usually in hex).
 326 urgent (bool)::
 327         Whether this container (window or workspace) has the urgency hint set.
 328 focused (bool)::
 329         Whether this container is currently focused.
 330
 331 Please note that in the following example, I have left out some keys/values
 332 which are not relevant for the type of the node. Otherwise, the example would
 333 be by far too long (it already is quite long, despite showing only 1 window and
 334 one dock window).
 335
 336 It is useful to have an overview of the structure before taking a look at the
 337 JSON dump:
 338
 339 * root
 340 ** LVDS1
 341 *** topdock
 342 *** content
 343 **** workspace 1
 344 ***** window 1
 345 *** bottomdock
 346 **** dock window 1
 347 ** VGA1
 348
 349 *Example:*
 350 -----------------------
 351 {
 352  "id": 6875648,
 353  "name": "root",
 354  "rect": {
 355    "x": 0,
 356    "y": 0,
 357    "width": 1280,
 358    "height": 800
 359  },
 360  "nodes": [
 361
 362    {
 363     "id": 6878320,
 364     "name": "LVDS1",
 365     "layout": "output",
 366     "rect": {
 367       "x": 0,
 368       "y": 0,
 369       "width": 1280,
 370       "height": 800
 371     },
 372     "nodes": [
 373
 374       {
 375        "id": 6878784,
 376        "name": "topdock",
 377        "layout": "dockarea",
 378        "orientation": "vertical",
 379        "rect": {
 380          "x": 0,
 381          "y": 0,
 382          "width": 1280,
 383          "height": 0
 384        },
 385       },
 386
 387       {
 388        "id": 6879344,
 389        "name": "content",
 390        "rect": {
 391          "x": 0,
 392          "y": 0,
 393          "width": 1280,
 394          "height": 782
 395        },
 396        "nodes": [
 397
 398          {
 399           "id": 6880464,
 400           "name": "1",
 401           "orientation": "horizontal",
 402           "rect": {
 403             "x": 0,
 404             "y": 0,
 405             "width": 1280,
 406             "height": 782
 407           },
 408           "floating_nodes": [],
 409           "nodes": [
 410
 411             {
 412              "id": 6929968,
 413              "name": "#aa0000",
 414              "border": "normal",
 415              "percent": 1,
 416              "rect": {
 417                "x": 0,
 418                "y": 18,
 419                "width": 1280,
 420                "height": 782
 421              }
 422             }
 423
 424           ]
 425          }
 426
 427        ]
 428       },
 429
 430       {
 431        "id": 6880208,
 432        "name": "bottomdock",
 433        "layout": "dockarea",
 434        "orientation": "vertical",
 435        "rect": {
 436          "x": 0,
 437          "y": 782,
 438          "width": 1280,
 439          "height": 18
 440        },
 441        "nodes": [
 442
 443          {
 444           "id": 6931312,
 445           "name": "#00aa00",
 446           "percent": 1,
 447           "rect": {
 448             "x": 0,
 449             "y": 782,
 450             "width": 1280,
 451             "height": 18
 452           }
 453          }
 454
 455        ]
 456       }
 457     ]
 458    }
 459  ]
 460 }
 461 ------------------------
 462
 463 === MARKS reply
 464
 465 The reply consists of a single array of strings for each container that has a
 466 mark. A mark can only be set on one container, so the array is unique.
 467 The order of that array is undefined.
 468
 469 If no window has a mark the response will be the empty array [].
 470
 471 === BAR_CONFIG reply
 472
 473 This can be used by third-party workspace bars (especially i3bar, but others
 474 are free to implement compatible alternatives) to get the +bar+ block
 475 configuration from i3.
 476
 477 Depending on the input, the reply is either:
 478
 479 empty input::
 480         An array of configured bar IDs
 481 Bar ID::
 482         A JSON map containing the configuration for the specified bar.
 483
 484 Each bar configuration has the following properties:
 485
 486 id (string)::
 487         The ID for this bar. Included in case you request multiple
 488         configurations and want to differentiate the different replies.
 489 mode (string)::
 490         Either +dock+ (the bar sets the dock window type) or +hide+ (the bar
 491         does not show unless a specific key is pressed).
 492 position (string)::
 493         Either +bottom+ or +top+ at the moment.
 494 status_command (string)::
 495         Command which will be run to generate a statusline. Each line on stdout
 496         of this command will be displayed in the bar. At the moment, no
 497         formatting is supported.
 498 font (string)::
 499         The font to use for text on the bar.
 500 workspace_buttons (boolean)::
 501         Display workspace buttons or not? Defaults to true.
 502 binding_mode_indicator (boolean)::
 503         Display the mode indicator or not? Defaults to true.
 504 verbose (boolean)::
 505         Should the bar enable verbose output for debugging? Defaults to false.
 506 colors (map)::
 507         Contains key/value pairs of colors. Each value is a color code in hex,
 508         formatted #rrggbb (like in HTML).
 509
 510 The following colors can be configured at the moment:
 511
 512 background::
 513         Background color of the bar.
 514 statusline::
 515         Text color to be used for the statusline.
 516 separator::
 517         Text color to be used for the separator.
 518 focused_workspace_text/focused_workspace_bg::
 519         Text color/background color for a workspace button when the workspace
 520         has focus.
 521 active_workspace_text/active_workspace_bg::
 522         Text color/background color for a workspace button when the workspace
 523         is active (visible) on some output, but the focus is on another one.
 524         You can only tell this apart from the focused workspace when you are
 525         using multiple monitors.
 526 inactive_workspace_text/inactive_workspace_bg::
 527         Text color/background color for a workspace button when the workspace
 528         does not have focus and is not active (visible) on any output. This
 529         will be the case for most workspaces.
 530 urgent_workspace_text/urgent_workspace_bar::
 531         Text color/background color for workspaces which contain at least one
 532         window with the urgency hint set.
 533
 534
 535 *Example of configured bars:*
 536 --------------
 537 ["bar-bxuqzf"]
 538 --------------
 539
 540 *Example of bar configuration:*
 541 --------------
 542 {
 543  "id": "bar-bxuqzf",
 544  "mode": "dock",
 545  "position": "bottom",
 546  "status_command": "i3status",
 547  "font": "-misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1",
 548  "workspace_buttons": true,
 549  "binding_mode_indicator": true,
 550  "verbose": false,
 551  "colors": {
 552    "background": "#c0c0c0",
 553    "statusline": "#00ff00",
 554    "focused_workspace_text": "#ffffff",
 555    "focused_workspace_bg": "#000000"
 556  }
 557 }
 558 --------------
 559
 560 === VERSION reply
 561
 562 The reply consists of a single JSON dictionary with the following keys:
 563
 564 major (integer)::
 565         The major version of i3, such as +4+.
 566 minor (integer)::
 567         The minor version of i3, such as +2+. Changes in the IPC interface (new
 568         features) will only occur with new minor (or major) releases. However,
 569         bugfixes might be introduced in patch releases, too.
 570 patch (integer)::
 571         The patch version of i3, such as +1+ (when the complete version is
 572         +4.2.1+). For versions such as +4.2+, patch will be set to +0+.
 573 human_readable (string)::
 574         A human-readable version of i3 containing the precise git version,
 575         build date and branch name. When you need to display the i3 version to
 576         your users, use the human-readable version whenever possible (since
 577         this is what +i3 --version+ displays, too).
 578
 579 *Example:*
 580 -------------------
 581 {
 582    "human_readable" : "4.2-169-gf80b877 (2012-08-05, branch \"next\")",
 583    "minor" : 2,
 584    "patch" : 0,
 585    "major" : 4
 586 }
 587 -------------------
 588
 589 == Events
 590
 591 [[events]]
 592
 593 To get informed when certain things happen in i3, clients can subscribe to
 594 events. Events consist of a name (like "workspace") and an event reply type
 595 (like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format
 596 as replies to specific commands. However, the highest bit of the message type
 597 is set to 1 to indicate that this is an event reply instead of a normal reply.
 598
 599 Caveat: As soon as you subscribe to an event, it is not guaranteed any longer
 600 that the requests to i3 are processed in order. This means, the following
 601 situation can happen: You send a GET_WORKSPACES request but you receive a
 602 "workspace" event before receiving the reply to GET_WORKSPACES. If your
 603 program does not want to cope which such kinds of race conditions (an
 604 event based library may not have a problem here), I suggest you create a
 605 separate connection to receive events.
 606
 607 === Subscribing to events
 608
 609 By sending a message of type SUBSCRIBE with a JSON-encoded array as payload
 610 you can register to an event.
 611
 612 *Example:*
 613 ---------------------------------
 614 type: SUBSCRIBE
 615 payload: [ "workspace", "focus" ]
 616 ---------------------------------
 617
 618
 619 === Available events
 620
 621 The numbers in parenthesis is the event type (keep in mind that you need to
 622 strip the highest bit first).
 623
 624 workspace (0)::
 625         Sent when the user switches to a different workspace, when a new
 626         workspace is initialized or when a workspace is removed (because the
 627         last client vanished).
 628 output (1)::
 629         Sent when RandR issues a change notification (of either screens,
 630         outputs, CRTCs or output properties).
 631 mode (2)::
 632         Sent whenever i3 changes its binding mode.
 633 window (3)::
 634         Sent when a client's window is successfully reparented (that is when i3
 635         has finished fitting it into a container), when a window received input
 636         focus or when a window title has been updated.
 637 barconfig_update (4)::
 638     Sent when the hidden_state or mode field in the barconfig of any bar
 639     instance was updated.
 640
 641 *Example:*
 642 --------------------------------------------------------------------
 643 # the appropriate 4 bytes read from the socket are stored in $input
 644
 645 # unpack a 32-bit unsigned integer
 646 my $message_type = unpack("L", $input);
 647
 648 # check if the highest bit is 1
 649 my $is_event = (($message_type >> 31) == 1);
 650
 651 # use the other bits
 652 my $event_type = ($message_type & 0x7F);
 653
 654 if ($is_event) {
 655   say "Received event of type $event_type";
 656 }
 657 --------------------------------------------------------------------
 658
 659 === workspace event
 660
 661 This event consists of a single serialized map containing a property
 662 +change (string)+ which indicates the type of the change ("focus", "init",
 663 "empty", "urgent").
 664
 665 Moreover, when the change is "focus", an +old (object)+ and a +current
 666 (object)+ properties will be present with the previous and current
 667 workspace respectively.  When the first switch occurs (when i3 focuses
 668 the workspace visible at the beginning) there is no previous
 669 workspace, and the +old+ property will be set to +null+.  Also note
 670 that if the previous is empty it will get destroyed when switching,
 671 but will still be present in the "old" property.
 672
 673 *Example:*
 674 ---------------------
 675 {
 676  "change": "focus",
 677  "current": {
 678   "id": 28489712,
 679   "type": "workspace",
 680   ...
 681  }
 682  "old": {
 683   "id": 28489715,
 684   "type": "workspace",
 685   ...
 686  }
 687 }
 688 ---------------------
 689
 690 === output event
 691
 692 This event consists of a single serialized map containing a property
 693 +change (string)+ which indicates the type of the change (currently only
 694 "unspecified").
 695
 696 *Example:*
 697 ---------------------------
 698 { "change": "unspecified" }
 699 ---------------------------
 700
 701 === mode event
 702
 703 This event consists of a single serialized map containing a property
 704 +change (string)+ which holds the name of current mode in use. The name
 705 is the same as specified in config when creating a mode. The default
 706 mode is simply named default.
 707
 708 *Example:*
 709 ---------------------------
 710 { "change": "default" }
 711 ---------------------------
 712
 713 === window event
 714
 715 This event consists of a single serialized map containing a property
 716 +change (string)+ which indicates the type of the change ("focus", "new",
 717 "title").
 718
 719 Additionally a +container (object)+ field will be present, which consists
 720 of the window's parent container. Be aware that for the "new" event, the
 721 container will hold the initial name of the newly reparented window (e.g.
 722 if you run urxvt with a shell that changes the title, you will still at
 723 this point get the window title as "urxvt").
 724
 725 *Example:*
 726 ---------------------------
 727 {
 728  "change": "new",
 729  "container": {
 730   "id": 35569536,
 731   "type": "con",
 732   ...
 733  }
 734 }
 735 ---------------------------
 736
 737 === barconfig_update event
 738
 739 This event consists of a single serialized map reporting on options from the
 740 barconfig of the specified bar_id that were updated in i3. The map always
 741 consists of a property +id (string)+, which specifies to which bar instance the
 742 sent config update belongs, a property +hidden_state (string)+, which indicates
 743 the hidden_state of an i3bar instance, and a property +mode (string)+, which
 744 corresponds to the current mode.
 745
 746 *Example:*
 747 ---------------------------
 748 {
 749     "id": "bar-0",
 750     "hidden_state": "hide"
 751     "mode": "hide"
 752 }
 753 ---------------------------
 754
 755 == See also (existing libraries)
 756
 757 [[libraries]]
 758
 759 For some languages, libraries are available (so you don’t have to implement
 760 all this on your own). This list names some (if you wrote one, please let me
 761 know):
 762
 763 C::
 764         i3 includes a headerfile +i3/ipc.h+ which provides you all constants.
 765         https://github.com/acrisci/i3-ipc (not yet ready for production use)
 766 Ruby::
 767         http://github.com/badboy/i3-ipc
 768 Perl::
 769         https://metacpan.org/module/AnyEvent::I3
 770 Python::
 771         * https://github.com/whitelynx/i3ipc
 772         * https://github.com/ziberna/i3-py (includes higher-level features)
 773 Go::
 774         * https://github.com/proxypoke/i3ipc