Put the ‘description’ column last. Since the last column is expanded
to fill the screen, and the tags’ descriptions can be fairly long, it
makes sense to put the description column last.
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
