The following modules used functions from the ‘m’ (math)
library (e.g. round()), but didn’t explicitly link against it. This
caused build failures when no other plugin that _did_ link against ‘m’
was enabled.
* cpu
* mem
* pulse
* pipewire
* foreign-toplevel
Closes#239
Before this patch, the cpu module instantiated a single particle (the
‘content’ particle), with one tag ("cpu") representing the total CPU
usage, and then one tag (cpuN) for each core.
This makes it cumbersome to configure, since you need to explicitly
reference each cpuN tag to get per-core usage.
This patch rewrites this, so that ‘content’ is now a template. It’s
instantiated once to represent the total CPU usage, and then once for
each core.
Each instance has a "cpu" tag, representing the CPU usage of that
core (or total usage). It also has an "id" tag. The ID is 0..n for
actual cores, and -1 for total usage.
This means you can do something like this in your config:
- cpu:
content:
map:
conditions:
id < 0: {string: {text: "Total: {cpu}%"}}
id >= 0: {string: {text: "Core #{id}: {cpu}%"}}
Closes#207
Implementing the move event required to pass the IPC socket to
`i3_ipc_callback_t`, because we won't get notified about any visibility
changes of other workspaces. That's why we query all workspaces again
after a focused workspace was moved.
A renamed workspace caused yambar to abort in a failed assertion,
because workspace lookup was done by name and the `rename` event was not
implemented. To resolve this issue this patch implements the `rename`
event and as a necessity changes workspace_lookup() to use ids instead
of names.
River seat status events are not fired if the river interface is bound
before the output globals are (despite
zriver_status_manager_v1_get_river_seat_status() not taking an output
as argument). See https://github.com/riverwm/river/issues/69 for
details.
Up until now, we had a workaround for this, where we deferred binding
the seat status interface until after all globals have been processed.
This did not help with runtime changes. For example, if a monitor is
turned off/on (with e.g. wlr-randr), all future river seat status
output events were lost, since the new output global was being
bound *after* the river seat status object.
This patch implements a new workaround, where we re-bind the river
seat status interface every time an output global is added.
Not sure if Sway bug or not, but we’ve seen Sway presenting multiple
input devices with the exact same ID (and nothing else differentiating
them).
This caused a crash in the sway-xkb module, since we didn’t check if
we were already tracking the device, and thus bumped the
“num_existing_inputs” variable multiple times for the same input
object.
This lead to a content() returning an array with uninitialized
elements, and thus a crash.
Closes#229
Recent kernels, or possibly updated wireless drivers, no longer
provide the SSID in `NL80211_CMD_NEW_STATION` responses.
For yambar, this meant the SSID was always missing.
This patch fixes this, by also issuing a NL80211_CMD_GET_SCAN
command. The response to this (NL80211_CMD_SCAN_RESULTS) _may_ return
many access points. Pick out the one that we’re associated with, and
inspect its BSS_INFORMATION_ELEMENTS. This is a raw data structure
containing, among other things, the SSID.
I haven’t been able to find any documentation of the format, but could
glean enough from
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/scan.c#n2313
to be able to parse out the SSID.
Note that we get a “device or resource busy” error if we try to issue
both the NL80211_CMD_GET_STATION and the NL80211_CMD_GET_SCAN commands
at the same time. Therefore, we issue the GET_SCAN command after
completing the GET_STATION command.
Closes#226
When the script module received multiple transactions in a single
batch, only the first were processed. This lead to multiple,
unprocessed transactions stacking up in the receive buffer. Every time
a new transaction was received, we popped the oldest transaction from
the buffer, but never actually getting to the last one. This is
perceived as "lag" by the user, where the bar displays outdated
information.
Closes#221
