2 changes to address the review feedback:
1. Aleksei pointed out in this
comment (https://github.com/Alexays/Waybar/pull/2971#issuecomment-1972364896)
that there's no way to tell if a proxy is alive other than trying to
call a method on it. We perform a little dance to check whether or
not power-profiles-daemon is available on the system by calling
properties.GetAll. If something responds, we assume
power-profiles-daemon is installed, it's then safe to draw the
widget and attach the callback to the active profile.
2. We replaced all the synchronous DBus operations by their async
counterparts.
We introduce a module in charge to display and toggle on click the
power profiles via power-profiles-daemon.
https://gitlab.freedesktop.org/upower/power-profiles-daemon
This daemon is pretty widespread. It's the component used by Gnome and
KDE to manage the power profiles. The power management daemon is a
pretty important software component for laptops and other
battery-powered devices.
We're using the daemon DBus interface to:
- Fetch the available power profiles.
- Track the active power profile.
- Change the active power profile.
The original author recently gave up maintenance on the project. The
Upower group took over the maintenance burden… …and created a new
DBus name for the project. The old name is still advertised for now.
We use the old name for compatibility sake: most distributions did not
release 0.20, which introduces this new DBus name. We'll likely revisit
this in the future and point to the new bus name. See the inline
comment for more details.
Given how widespread this daemon is, I activated the module in the
default configuration.
Fixes#2945
Split the config and rule persistency in 2 attributes, one storing the
persistency as set in Waybar's config, the other one storing the
persistency as set in Hyprland.
It fixes some conflicts between the persistency state of a workspace as
set in Waybar's config and its dynamic state in Hyprland.
It allows to remove a persistent workspace in Waybar if this workspace
is removed from Hyprland and if the workspace is not set as persistent
in Waybar's config.
```
../include/util/date.hpp:34:26: warning: literal operator suffixes not preceded by ‘_’ are reserved for future standardization [-Wliteral-suffix]
34 | constexpr decltype(auto) operator""d(unsigned long long d) noexcept {
```
While we at it, eliminate use of non-portable GCC conditional expression
syntax. There are no significant side-effects that would justify use of
the language extension.
BREAKING CHANGE: gtk-layer-shell is now required and unconditionally
used. The corresponding config option is removed.
As a part of preparation for future versions of GTK, remove an ability
to use wlr-layer-shell directly. The APIs it required were dropped in
GTK4, and with the menus/tooltips positioning issue being practically
unsolvable it doesn't make sense to keep maintaining the code.
We already use it without checking (`<gio/gdesktopappinfo.h>` in
wlr/taskbar), it's a transitive dependency of GTK and it's always
available on Unix platforms.
The `<experimental/filesystem>` and `-lc++experimental` aren't needed
since LLVM 9.0. And since we now require C++20, checking for the
`<filesystem>` support shouldn't be necessary either.
Previously, the only way to select all the module labels was with the
following kind of selector:
```css
.modules-left > widget > label,
.modules-center > widget > label,
.modules-right > widget > label {
/* ... */
}
```
(and a matching block for the `box` containers).
Now, this can be expressed as
```css
label.module, box.module {
/* ... */
}
```
Background and Motivation
-------------------------
When the `hwmon-path-abs` and the `input-filename` fields are used for
the temperature module, we evaluated the following path:
```
[hwmon-path-abs] / [gap] / [input-filename]
```
where `gap` is the first file or directory in the `hwmon-path-abs`
directory. This usually works but it doesn't seem to work for NVME or
WiFi temperature sensors. For those cases, there are a bunch of other
files in the `hwmon-path-abs` directory. In the bad case, the first
selected file is not the one with the prefix `hwmon` and we end up
checking the wrong location for the `input-filename`.
Change description
------------------
We are simply going through the `hwmon-path-abs` directory and searching
for the first file/directory that begins with `hwmon`.
Test case
---------
I tested this on a AMD based Framework 13 laptop.