This is mainly to fix a race when river is *not* running; sometimes we
ended up allocating particles for N seats in content(), but then when
iterating the seats, run() had destroyed all, or some of the seats,
causing us to feed NULL pointers to dynlist, which crashed.
* Verify int/float/bool values are that, and nothing else
* Verify tag ranges are integers
* Verify a range tag value is inside its range
* Don’t allow anything but false|true for booleans
User is expected to send ‘false’ or ‘true’. But we were parsing the
value using `strtol()`. This caused all bools to be false, since
`strtol()` would always return 0.
This module exec’s a script (or binary), specified by the ‘path’
attribute in the configuration.
It then reads tags from the script’s stdout.
The format of the output is:
tag|type|value
tag|type|value
<empty line>
I.e. the script writes N tags followed by an empty line. This
constitutes a transaction.
When a new transaction is received, its tags replaces *all* previous
tags.
We overloaded enum mpd_state to add an “offline” state. Don’t do
this. We can detect the offline state by checking if our connection
object is NULL.
Closes#16
The ‘river’ module depends on generated protocol sources. These are
normally provided, indirectly, by the Wayland bar backend. But when
building plugins as shared modules, the plugins no longer depend on
the bar, and thus ‘river’ fails to build.
Fix this by doing two things:
* **Remove** the ‘river’ protocol from the ‘generic’ Wayland protocols
* Explicitly add both the generic and the ‘river’ specific protocols
to the ‘river’ module.
Time remaining is now taken from 'time_to_empty_now' if available. If
not, use 'energy' + 'power' if available, and if those does not exist,
use 'charge' + 'current'.
If neither exists, hardcode to 99:00.
This means you can now do either
ignore: [/dev/sda]
to ignore all partitions on /dev/sda, or
ignore: [/dev/sda1]
to ignore only the first partition on /dev/sda.
Don't fail (and terminate the i3 plugin) if we receive a window event
where the 'container' doesn't have a 'pid' property.
This means we won't be able to determine the application the window
belongs to.
Closes#2
We previously used the 'pid' property of the 'container' object in a
window event to lookup the application name under /proc/<pid>/comm.
In many cases, the application name is already available in the window
event itself, in the 'app_id' property.
Use this, if available, and fallback to the old PID method otherwise.
A quick experiment suggests 'app_id' is set for all Wayland native
applications, but not for X11 applications running under XWayland.
