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
If a window is created on an unfocused workspace, yambar did not
update the empty tag correctly. At least not for persistent
workspaces.
This is because yambar relies on focus events to determine a
workspace's "empty" state. Since the new window, on the new workspace,
isn't focused, there's no focus event, and yambar thinks the workspace
is still empty.
This patch changes the logic slightly; a new workspace is considered
non-empty if it isn't focused (and has a non-zero node count).
Closes#191
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.
This ensures particles that are “too wide” doesn’t try to render
outside the bar, possibly overrunning both margins and borders. Or
worse, crashes yambar.
Closes#198
If a device is removed while the computer is hibernating, and then
reconnected after waking it up, Sway sends an “added” event without
first sending a “removed” event.
Yambar used to assert that an “added” event didn’t refer to an already
tracked device.
This patch changes this, and simply ignores duplicate “added” events.
Closes#177
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> ""
/proc/stat lists CPU usage, in the form:
cpu ...
cpu0 ...
cpu1 ...
...
cpuN ...
where the first line is a summary line. We’ve been using the CPU
numbers from /proc/stat to index into our internal stats array.
This doesn’t work on systems where the core IDs aren’t
consecutive. Examples of such systems are SMT systems with SMT
disabled. Here, /proc/stat may look like this instead:
cpu ...
cpu0 ...
cpu2 ...
cpu4 ...
...
With this patch, we ignore the CPU ID from /proc/stat. Instead, we use
a simple counter that is incremented for each (valid) cpu line found
in /proc/stat. To protect against corrupt /proc/stat content, stop
parsing /proc/stat if the number of parsed CPU lines exceed what we
consider to the be total number of CPUs in the system.
Closes#172
All FDs should now have the CLOEXEC flag set, and thus there’s no
longer needed to manually loop “all” possible FDs and (trying to)
close them.
Note: the alsa module (alsalib, actually) is “racy” - while booting
up, it temporarily opens the asoundrc file without CLOEXEC. If
e.g. the script module starts its script inside this window, it’ll
have a leaked FD. Not much we can do about it though :/
Closes#169
This ensures we don’t leak FDs when exec:ing e.g. on-click
handlers.
Note that the comm-pipe FD is *supposed* to stay open when we execing
the script. This is handled by the call to dup2(), which drops the
CLOEXEC flag. Since dup2() is called after the fork, the dup:ed FD is
never visible in the “parent” yambar process.
Use the (relatively new) macro __has_include() to check if
stdc-predef.h exists, and only include it if it does.
If stdc-predef.h does not exist, or if the compiler does not implement
__has_include(), stdc-predef.h is *not* included.
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.
