Flex regexps are greedy.
This means '"foo" || "bar"' will return 'foo" || "bar', which is
obviously wrong.
Use "start conditions" to implement non-greedy matching.
Closes#302
We now do tilde expansion of the *first* argument in on-click
handlers.
That is:
~/bin/foobar.sh ~/arg1
is expanded to
$HOME/bin/foobar.sh ~/arg1
(meaning, the handler will most likely *not* do what you’d expect)
Related to #307
We may receive udev notifications for the power-supply subsystem, that
aren’t for us.
Before this patch, this would result in a new poll() call, with
timeout being set to m->poll_interval again. That is, the poll timeout
was being reset.
In theory, this means we could end up in a situation where the battery
status is never updated.
This patch fixes it by tracking how much time is left of the poll
interval. The interval is reset either when the timeout has occurred,
or when we receive an udev notification that _is_ for us.
Hopefully closes#305
The kernel also provides time_to_full, also in seconds, so let's use
that too. Both time_to_empty and time_to_full have 0 as their default
value, hence only consider them for the estimate if they are
positive (instead of non-negative).
Signed-off-by: David Bimmler <git@d4ve.email>
The kernel docs state that time_to_empty contains the estimation of
remaining time in seconds. Hence, calculate estimate minutes and hours
from that in a more correct way.
Signed-off-by: David Bimmler <git@d4ve.email>
When merging an anchor into a target yaml node, and both the target
node and the anchor defines the same key(s), keep the value from the
target node.
Closes#286
dwl added an "appid" field as output status [1]. We currently don't
handle this field, and thus output warnings that say "UNKNOWN action".
Handle the "appid" field correctly and expose a value of this field to
users. Also, suppress the warnings.
Link: 7f9a212476 [1]
bbd2394601 added support for ‘rename’
and ‘move’ events. In order to do that, it changed how workspace
events are matched against our internal workspace list: from string
comparing the workspace name, to checking i3/sway’s workspace ID
parameter.
This introduced a regression in our handling of persistent
workspaces. A persistent workspace is one that isn’t removed from the
bar when it’s deleted (empty, and switched away from) by i3/sway.
This concept doesn’t exist in i3/sway, but is something we’ve
added. Put simple, the way we do this is be keeping the workspace in
our list, even when i3/sway tells us it has been deleted.
However, at this point the workspace doesn’t have an ID anymore. And
the same is true at startup; when we initialize the persistent
workspaces, we only have their names. Not their IDs (since the
workspaces don’t actually exist yet).
To this the regression, we need to:
a) fallback to looking up workspaces by name. That is, if we fail to
find one with a matching ID, try again using the workspace name. For
_this_ to match, we also required the matched workspace to be a
persistent workspace, with an ID < 0 (which essentially means the
workspace doesn’t exist yet).
b) reset the ID to -1 when a persistent workspace is "deleted".
Closes#253
Uupdate the title when process a new batch of info instead of call
strtok_r and looping until `string` is NULL.
This fixes an issue where only the last part of the title was kept.
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
'-' is a valid character for tags.
Commit 03e1c7d (module/network: Add link stats, 2022-04-30) introduced
two new tags for the network module: `ul-speed` and `dl-speed`. These
use the `-` character, that was previously never used in any tag.
We had two options: either change those tags to use `_` instead, or just
accept `-`s as a valid character. Going forward, I can see many people
deciding to name their tags with `-` instead of `_`, so I believe it is
better to just accept it once and for all.
Note that `-` cannot be used as the first character of a tag (e.g.
`-tag1`) since the `-` has a special meaning in `.yml` files. I don't
believe this will happen often, however, and should be easy to both
detect and correct if it does.
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
For channels that have a defined dB range, use that instead of the raw
volume range when calculating the volume percent.
Also use the same logic as alsamixer when calculating the percent from
the dB values: assume a linear scale if the dB range is “small
enough”, and otherwise normalize it against a logarithmic scale.
With this, yambar’s “percent” value matches alsamixer’s exactly.
The ‘volume’ tag remains unchanged - it always reflects the raw volume
values.
Instead, we add a new tag ‘dB’, that reflects the dB values.
Closes#202
