This adds some detail to the workspace events documentation and is
written along the same lines as the window events documentation. This
was brought up in [#4392 (issue)](https://github.com/i3/i3/issues/4392).
We do this by adding to included_files as i3 processes the configs.
This should allow for easy debugging, without having to change how i3 processes
config files.
related to #4192
This helps write correct descriptions of the JSON schema for strongly
typed languages that support deserializing to native types (and
require a different type for null).
These seemed to be inconsistently specified.
Particularly, the "SYNC" message payload was not described anywhere.
Even when the payload is empty, it is helpful to specify that
explicitly, as it prevents the reader from having to guess whether if
it's really empty, or otherwise somehow implicitly obvious.
The "Reply format" section is now "Messages and replies", and covers
both the reply format and the format of sent messages.
- Make sure to place the description of the packet before the
description of the payload.
- Describe the relationship of messages and replies.
- Add note on pipelining.
This is achieved by retaining the IPC connection which is sending the restart
command across the restart.
This is the cleaner fix for https://github.com/i3/go-i3/issues/3fixes#3565
This change only affects clients that are subscribed to events, which
should be the main cause of our problems.
In the common case (no buffered data) the behaviour doesn't change at
all: the message is sent directly, no ev_io / ev_timeout callback is
enabled. Once a write to a client's socket is not completed fully
(returns with EAGAIN error), we put the message in the tail of a queue
and init an ev_io callback and a corresponding timer. If the timer is
triggered first, the socket is closed and the client connection is
removed. If the socket becomes writeable before the timeout we either
reset the timer if we couldn't push all the buffered data or completely
remove it if everything was pushed.
We could also replace ipc_send_message() for all client connections in
i3, not just those subscribed to events.
Furthermore, we could limit the amount of messages stored and increase
the timeout (or use multiple timeouts): eg it's ok if a client is not
reading for 10 seconds and we are only holding 5KB of messages for them
but it is not ok if they are inactive for 5 seconds and we have 30MB of
messages held.
Closes#2999Closes#2539
Sending the sync command via IPC ensures pending IPC messages are handled by i3
before the sync response is read. This is rarely useful for direct IPC
connections to i3, but becomes useful when synchronizing with i3bar, which might
have pending IPC messages in response to button clicks.
All other message types are verbs, only our first-ever message COMMAND wasn’t.
While we’re here, also change the message type dictionary into a table with
clickable links to the corresponding reply type.
Authors of downstream IPC libraries are encouraged to keep the old name around
so as to not break existing code, but mark it as deprecated.
