`format-discharging-full` has been impossible since #923 made it
impossible to be full and discharging at the same time. This should
fix that by only making `format-charging-full` impossible. Whether
or not that should be allowed is a good question, but beyond the
scope of this change.
Fixes#1031
std::regex and std::regex_replace may throw an std::regex_error if the
expression or replacement contain errors.
Log this error and carry on with the next rule, so that the title is
shown even if the config contains errors.
Rewrites window title according to config option "rewrite".
"rewrite" is an object where keys are regular expressions and values are
rewrite rules if the expression matches. Rules may contain references to
captures of the expression. Regex and replacement follow ECMA-script
rules. If no regex matches, the title is left unchanged.
example:
"sway/window": {
"rewrite": {
"(.*) - Mozilla Firefox": " $1",
"(.*) - zsh": " $1",
}
}
Allow the user to show the current volume from MPD status via the
`format` and/or `tooltip-format` configuration options.
The values are provided by libmpdclient and are integers, generally
between 0-100 (without %). Values above 100 are also possible, as mpd
output plugins like `pulse` support volumes above 100%.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
On some systems (eg: ARM) the supported frequencies of the CPU are not
properly reported by /proc/cpuinfo so if that fails try to retrieve them
from /sys/devices/system/cpu/cpufreq/policy[0-9]/cpuinfo_[max|min]_freq.
(Fixes #358.)
Subprocesses created for custom module scripts were previously left
running when the parent Waybar process exited. This patch sets the
parent-death signal of child processes (PR_SET_PDEATHSIG on Linux,
PROC_PDEATHSIG_CTL on FreeBSD) to SIGTERM.
Caveats:
* This uses Linux-specific or FreeBSD-specific calls. I don’t know if
this project targets other systems?
* There is a possibility that Waybar exits after calling `fork()`, but
before calling `prctl` to set the parent-death signal. In this case,
the child will not receive the SIGTERM signal and will continue to
run. I did not handle this case as I consider it quite unlikely, since
module scripts are usually launched only when Waybar starts. Please
let me know if you think it needs to be handled.
Testing:
* With `htop` open, run Waybar v0.9.5 with a custom module that has an
`exec` script. Terminate the Waybar process and notice that the
script’s subprocess stays alive and is now a child of the init
process.
* Run Waybar with this patch and follow the same steps as above. Notice
that this time the script’s subprocess terminates when the parent
exits.
Moving rfkill to the main event loop had unexpected side-effects.
Notably, the network module mutex can block all the main thread events
for several seconds while the network worker thread is sleeping.
Instead of waiting for the mutex let's hope that the worker thread
succeeds and schedule timer thread wakeup just in case.
Open rfkill device only once per module.
Remove rfkill threads and use `Glib::signal_io` as a more efficient way
to poll the rfkill device.
Handle runtime errors from rfkill and stop polling of the device instead
of crashing waybar.