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
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]
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.
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.
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
Exports two new tags from network module, `ul-speed` and `dl-speed`.
Because these work through polling, poll-interval must be set.
Otherwise, these two tags always will be 0.
Seat status v3 adds a new ‘mode’ event, that informs us of the current
mode (as set by e.g. ‘riverctl enter-mode passthrough’)
The mode is exposed as a tag (named “mode”) on river’s “title”
particle:
- river:
title:
map:
default: {empty: {}}
conditions:
mode == passthrough:
string: {text: " {mode} ", deco: {background: {color: ff0000ff}}}
A condition is formed by:
<tag> <op> <value>
<tag> is the normal yambar tag. <op> is one of '==', '!=', '<', '<=', '>', or
'>='. <value> is what you wish to compare it to.
'boolean' tags must be used directly. They falsehood is matched with '~':
<tag>
~<tag>
Finally, to match an empty string, one must use ' "" ':
<tag> <op> ""
This patch adds an inheritable option, “font-shaping”, that controls
whether a particle that renders text should enable font-shaping or
not.
The option works similar to the ‘font’ option: one can set it at the
top-level, and it gets inherited down through all modules and to their
particles.
Or, you can set it on a module and it gets inherited to all its
particles, but not to other modules’ particles.
Finally, you can set it on individual particles, in which case it only
applies to them (or “child” particles).
When font-shaping is enabled (the default), the string particle shapes
full text runs using the fcft_rasterize_text_run_utf32() API. In fcft,
this results in HarfBuzz being used to shape the string.
When disabled, the string particle instead uses the simpler
fcft_rasterize_char_utf32() API, which rasterizes individual
characters.
This gives user greater control over the font rendering. One example
is bitmap fonts, which HarfBuzz often doesn’t get right.
Closes#159
On i3, users are currently greeted with:
err: modules/i3.c:94: workspace reply/event without 'name' and/or
'output', and/or 'focus' properties
This patch makes ‘focus’ an optional attribute. When missing, we
assume a node-count of 0, which means the workspace’s ‘empty’ tag will
always be true. Document this in the i3 man page.
