This starts up the event loop and wayland display and shims out the
basic top level rendering concepts. Also includes some changes to
incorporate pango into the 1.x codebase properly.
Calling `exit` in sway_terminate prevents sway from correctly shutting
down (freeing data, cleanly terminating the ipc server, etc.).
A better way is to exit straight away if the failure occurs before
`wlc_run` and use sway_abort as usual if it occur when wlc is running.
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.
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.
I am not sure if this is a correct issue/fix but on my system at least
after an i3bar protocol is detected this while loop never goes back
around meaning it doesnt process the status line anymore.
Swaybar did not correctly handle the SIGTERM sent from sway when
exiting, ultimately leaving the child status_command behind.
This should correctly handle the SIGTERM signal and terminate the
status_command.
Fix#386
Use of busyloop caused high cpu usage for sway because swaybar had to be
redrawn all the time. By using select instead the bar only has to be
redrawn when the status_command changes (i.e. every second) or when the
workspaces are updated.
Fix#345
