summary:
-------
This commit adds xdg-desktop-portal support to waybar. If a portal
supporting `org.freedesktop.portal.Settings` exists, then it will be
queried for the current colorscheme. This colorscheme will then be used
to prefer a `style-light.css` or `style-dark.css` over the basic
`style.css`.
technical details:
-----------------
Appearance is provided by several libraries, such as libhandy (mobile)
and libadwaita. However, waybar links to neither of these libraries. As
the amount of code required to communicate with xdg-desktop portal as a
client is rather minimal, I believe doing so is better than linking to
an additional library.
The Gio library for communicating with dbus is rather messy, Instead of
the `Portal` class containing a `Gio::Dbus::Proxy`, it extends it which
simplifies signal handling.
`Portal` then exposes its own signal, which can be listened to by waybar
to update CSS.
For a reference implementation, please see another one of my projects:
https://github.com/4e554c4c/darkman.nvim/blob/main/portal.go
test plan:
---------
If no desktop portal which provides `Settings` exists, then waybar
continues with the log line
```
[2023-09-06 14:14:37.754] [info] Unable to receive desktop appearance: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
```
Furthermore, if `style-light.css` or `style-dark.css` do not exist, then
`style.css` will still be searched for.
Waybar has been tested with both light and dark startup. E.g. if the
appearance is dark on startup the log lines
```
[2023-09-06 14:27:45.379] [info] Discovered appearance 'dark'
[2023-09-06 14:27:45.379] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style-dark.css
[2023-09-06 14:27:45.379] [debug] Found config file: $XDG_CONFIG_HOME/waybar/style-dark.css
[2023-09-06 14:27:45.379] [info] Using CSS file /home/pounce/.config/waybar/style-dark.css
```
will be observed.
If the color then changes to light during the operation of waybar, it
will change css files:
```
[2023-09-06 14:28:17.173] [info] Received new appearance 'dark'
[2023-09-06 14:28:17.173] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style-light.css
[2023-09-06 14:28:17.173] [debug] Found config file: $XDG_CONFIG_HOME/waybar/style-light.css
[2023-09-06 14:28:17.173] [info] Using CSS file /home/pounce/.config/waybar/style-light.css
```
Finally, tested resetting waybar and toggling style (works, and style is
only changed once).
fixes: Alexays/Waybar#1973
The segfaults were happening on GTK icon theme functions, which are
called via the C++ interface functions such as Gtk::IconTheme::has_icon.
There are multiple modules and threads using this functions on the default
icon theme by calling Gtk::IconTheme::get_default(), which returns the same
object for all callers, and was causing concurrent access to the same internal
data structures on the GTK lib. Even a seemingly read-only function such as
has_icon can cause writes due to the internal icon cache being updated.
To avoid this issues, a program wide global mutex must be used to ensure
a single thread is accessing the default icon theme instance.
This commit implements wrappers for the existing IconTheme function calls,
ensuring the global lock is held while calling the underling GTK functions.
Avoids a race where the pipe could be inherited by another process
spawning at about the same time. If the other process didn't exit
quickly (e.g. if it was a custom script that did its own looping), it
would keep the write end of the pipe open, and so reading from the pipe
to try to get the command's output would block.
This bug manifested as some custom modules randomly not appearing in the
bar, requiring a reload to fix. The custom script had run and exited,
but the pipe had been inherited by another process, and the thread that
updated the module's output was blocked trying to read from it.
Use chrono Calendars and Time Zones (P0355R7, P1466R3) when available
instead of the `date` library.
Verified with a patched build of a recent GCC 13 snapshot.
There were two main issues with fmtlib and C++20 mode:
- `fmt::format` defaults to compile-time argument checking and requires
using `fmt::runtime(format_string)` to bypass that.
- `std::format` implementation introduces conflicting declarations and
we have to specify the namespace for all `format`/`format_to` calls.
The structure was used to pass the locale instance to the date
formatter. All the supported versions of `fmt` are passing the locale
parameter via `FormatContext.locale()` so we can remove the struct and
simplify the code.
While we at it, drop `date::make_zoned` in favor of CTAD on a
`date::zoned_time` constructor.
gtk requires some chars (<>&"') to be encoded for them to render
properly. `sanitize_str` sanitizes raw strings that have such chars and
returns a properly encoded string
Stop using private implementation details of the `formatter<std::tm>`.
We never needed anything from the class besides the format specifier,
which is easily obtainable with public API.
The changes in GCC 11.x made `std::condition_variable` implementation
internals `noexcept`. `noexcept` is known to interact particularly bad
with `pthread_cancel`, i.e. `__cxxabiv1::__force_unwind` passing through
the `noexcept` call stack frame causes a `std::terminate` call and
immediate termination of the program
Digging through the GCC ML archives[1] lead me to the idea of patching
this with a few pthread_setcancelstate's. As bad as the solution is, it
seems to be the best we can do within C++17 limits and without major
rework.
[1]: https://gcc.gnu.org/legacy-ml/gcc/2017-08/msg00156.html
(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.
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.
Other units are all uppercased, so using an uppercased "K" makes it look more consistent (especially when {bandwidthUpBits} or something like that is used).
Implement a wrapper over Glib::Dispatcher that passes the arguments to
the signal consumer via synchronized `std::queue`.
Arguments are always passed by value and the return type of the signal
is expected to be `void`.
When forkExec is called it begins to ignore all SIGCHLD signals for
the rest of the progam's execution so that they are automatically
reaped. However, this means that subsequent waitpid calls in the exec
function will always fail. So instead handle SIGCHLD by reaping any
processes created by forkExec and ignoring all others so that they can be
handled directly by the exec function.
In file included from ../src/modules/custom.cpp:1:
In file included from ../include/modules/custom.hpp:7:
../include/util/command.hpp:15:25: error: implicit instantiation of undefined template 'std::__1::array<char, 128>'
std::array<char, 128> buffer = {0};
^
../src/modules/pulseaudio.cpp:175:41: error: implicit instantiation of undefined template 'std::__1::array<std::__1::basic_string<char>, 9>'
static const std::array<std::string, 9> ports = {
^
/usr/include/c++/v1/__tuple:223:64: note: template is declared here
template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;
^
In file included from ../src/factory.cpp:1:
In file included from ../include/factory.hpp:8:
../include/modules/sway/workspaces.hpp:39:8: error: no template named 'unordered_map' in namespace 'std'
std::unordered_map<std::string, Gtk::Button> buttons_;
~~~~~^
../src/factory.cpp:20:14: error: cannot initialize return object of type 'waybar::AModule *' with an rvalue of type 'waybar::modules::sway::Workspaces *'
return new waybar::modules::sway::Workspaces(id, bar_, config_[name]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This patch adds 3 new configuration options applicable for
subclasses of ALabel. The options can be used to execute
user defined code in response to the 3 mouse events:
* on-click: The left mouse button click
* on-scroll-up
* on-scroll-down
This patch also modifies the behaviour of the format-alt toggle
such that when the on-click event is configured, format-alt is
toggled on any mouse click other than left click. When on-click
is not defined, any mouse button would toggle format-alt.
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>