i3wm's IPC makes a distinction between message types and reply types. i3wm's IPC protocol internally assign the same values to both message and reply of a certain type.

/*
 * Messages from clients to i3
 *
 */
#define I3_IPC_MESSAGE_TYPE_RUN_COMMAND 0
...
#define I3_IPC_MESSAGE_TYPE_GET_MARKS 5
#define I3_IPC_MESSAGE_TYPE_GET_BAR_CONFIG 6
#define I3_IPC_MESSAGE_TYPE_GET_VERSION 7
...
#define I3_IPC_MESSAGE_TYPE_GET_BINDING_STATE 12
 
 
/*
 * Messages from i3 to clients
 *
 */
#define I3_IPC_REPLY_TYPE_COMMAND 0
...
#define I3_IPC_REPLY_TYPE_MARKS 5
#define I3_IPC_REPLY_TYPE_BAR_CONFIG 6
#define I3_IPC_REPLY_TYPE_VERSION 7
...
#define I3_IPC_REPLY_TYPE_GET_BINDING_STATE 12

https://github.com/i3/i3/blob/next/include/i3/ipc.h

This fact was taken advantage of to completely remove this disinction in qi3pc. The same enum (qi3pc::IpcType) is used for both messages and replies.

Signals

Replies and events from i3wm are available through signals.

Introduction to Qt's signals and slots

In qi3pc, a distinction is made between an event and a reply.

Reply signals

These signals are fired as the result of a reply to a message sent to the window manager. For example, when a fetch message is sent by calling qi3pc::fetchWorkspaces, the reply will come asynchronously in the form of a signal, in this case qi3pc::workspacesUpdated. Reply signals names are usually in the past participle.

In Qt lingo, these fetch messages are known as slots. They usually indicate an asynchronous work request.

The parameters supplied with those signals are cached by the qi3pc object. Their values can be retrieved synchronously through the appropriate methods, e.g. qi3pc::workspaces.

These cached values can however be out-of-date. They are only updated when the window manager replies to a fetch message. The last update time is stored with the cached values. For example, qi3pc::workspaces returns a qi3pc::DataArray object, which is an optional pair of the cached value as a QJsonArray and its last update time in milliseconds since the unix epoch as a qint64.

Event signals

Those signals are fired as a result of some independent change happening in the window manager, like a new workspace or window being created. Event signals are usually suffixed with Event, e.g. qi3pc::workspaceEvent.

The parameters supplied with those signals are not cached by the qi3pc object. The user of the library should save them themself if necessary for later use. Otherwise, they have to be queried from the window manager asynchronously with a fetch message.

Message parsing

Messages from i3wm are generally not parsed by qi3pc. Beyond conversion to the appropriate Qt-based type (e.g. QJsonObject, QJsonArray, QString, etc.), the message is communicated as received. That is always true for replies.

Some minimal parsing is done for some event types. The goal in those cases is to extract the kind of change i3wm is notifying. For example, a qi3pc::windowEvent can be triggered when a window is created, closed, gained focus, moved, etc. In addition to the message from i3wm, the type of change is provided through a change enum, in this case qi3pc::WindowChange.