Detects when a bar modifier key is pressed/released and sends a modifier
IPC event to any listeners (usually swaybars).
This way a swaybar can listen on the modifier event and hide/show the
bar accordingly (not implemented yet)
The modifier event looks like this:
{
"change": "pressed", // or released
"modifier": "Mod4"
}
This fixes a bug where the key at index 0 in the `key_state_array` would
be overwritten by the next pressed key. This broke any bindings
consisting of multiple non-mod keys like: `$mod+a+b`.
Makes `ipc_recv_response` return a struct with size, type and payload
rather than just the payload string.
This is useful if the type has to be checked on the client.
If the width or height of a container can't be evenly distributed to its
children, then the layout algorithm still thought it got it right (due
to using decimals) which caused a gap of one or more pixels for some
window arrangements.
This is fixed by this patch by first rounding off the width and height
(so that decimals are never introduced) and then adjusting the last
view in a container to fill the remaining pixels (which now is counted
correctly due to the decimals being removed).
Also, due to the way gaps are implemented, an odd sized gap can never be
aligned properly, so just adjust to closest even number.
This extends the i3bar protocol implementation with the following
features from @Airblade/i3:
* background
* border
* border_top, border_bottom, border_left, border_right
A block will now be rendered like this:
```
(border_left + margin) + width + (margin + border_right) + sep
```
Where `border_left/border_right` and their related margin is only drawn
if the `border` is specified and the border has a width > 0 (default is
1).
`border_top` and `border_bottom` does not affect the height of the bar
(no margin is added), thus it will be drawn behind the text if it is too
big. The user should specify a bar height if more space between
top/bottom borders are required.
This should fix the random json related crashes in swaybar.
The crashes occured because the same socket was used for listening on
workspace events and requesting workspace info, resulting in a
unreliable message queue on the socket.
The solution is to use one socket for the events and one socket for
reliably requesting workspace/output info.
