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.
All decoration, particle and module interfaces now takes a
pixman_image_t parameter, and all drawing is done using pixman APIs.
The wayland/xcb backends implement a new interface functions,
get_pixman_image(), that should return a pixman image instance that is
suitable for rendering.
In the wayland backend, the image uses the same backing data as the
cairo surface.
In the XCB backend, we create a new image each time, and then blit it
to the cairo surface at commit time.
