Currently, modules polling hardware nodes continuously wake up kernel drivers even when the monitor is asleep (e.g., DPMS off), flooding dmesg.
- Adds 'disable-on-sleep' config flag
- Hooks GTK window map/unmap signals to track DPMS state
- Propagates suspend/resume calls to AModule worker threads
Add opt-in bar-css-states option to wlr/taskbar module.
When enabled, the module tracks the active workspace and updates CSS
classes on window#waybar to reflect the current window state:
- toplevel-active: when a window is focused
- toplevel-maximized: when any non-minimized window on active workspace is maximized
- toplevel-minimized: when the active window is minimized
- toplevel-fullscreen: when any non-minimized window on active workspace is fullscreen
This feature requires compositor support for ext-workspace-v1 protocol
to correctly track workspace membership. Without it, classes fall back
to the active application state only.
Also includes active-only option implementation.
Changes:
- Add ext-workspace-v1 protocol support for workspace tracking
- Implement WorkspaceState tracking in Taskbar class
- Add workspace management lifecycle (create/remove/done)
- Add bar CSS class update logic with aggregation
- Add visible() getter to Task class
- Implement active-only task visibility control
- Update man page with documentation and CSS examples
Signed-off-by: iamcheyan <iamcheyan@users.noreply.github.com>
Fixes a bug where removing a hot-plugged device mid-loop causes a filesystem error that turns into a fatal runtime error that crashes waybar entirely, changed to warning instead of runtime error.
### Problem
Waybar segfaults on startup when `niri/workspaces` is the only configured
module (default options). Right after the first `WorkspacesChanged` event:
Thread 1 "waybar" received signal SIGSEGV
#0 gtk_label_set_markup ()
#1 waybar::modules::niri::Workspaces::doUpdate () at src/modules/niri/workspaces.cpp:106
### Root cause
[doUpdate()](cci:1://file:///home/lj/Downloads/Waybar/src/modules/niri/window.cpp:27:0-90:1) set the label markup via:
static_cast<Gtk::Label*>(button.get_children()[0])->set_markup(name);
The button's child *is* a valid `GtkLabel`, but gtkmm's `get_children()`
returns it wrapped as a generic `Gtk::Widget` (confirmed: `dynamic_cast`
to `Gtk::Label*` yields `nullptr`). The unchecked `static_cast` then
performs an invalid downcast, producing a corrupt pointer whose `gobj()`
is garbage (`0x1`), so `gtk_label_set_markup()` dereferences it and crashes.
This is reliably triggered when no other module has instantiated a
`Gtk::Label` yet (so the `Gtk::Label` wrapper isn't registered), which is
exactly the case for a `niri/workspaces`-only bar. The same idiom exists in
`sway/workspaces` and `wayfire/workspaces`; it's masked there because typical
configs include other label-using modules.
### Testing
- Reproduced the crash on 0.15.0 / current `master` with a minimal
`"modules-left": ["niri/workspaces"]` config under niri.
- After the fix: no crash; three workspace buttons render with correct
names/labels (`niri-workspace-1/2/3`).
When Host::proxyReady fails to create the SnWatcher proxy (e.g. because
the Watcher has not finished exporting /StatusNotifierWatcher yet), the
cancellable is left set, causing nameAppeared to early-return on every
subsequent event (see the // TODO marker). The Host is then stuck
without a watcher, and the tray module reports
'No such object path /StatusNotifierWatcher' until the bar is fully
restarted.
Clear the cancellable on non-CANCELLED errors and schedule a single
delayed retry of nameAppeared. The guard `watcher_ != nullptr` skips
the retry if a parallel call already succeeded.
Closes#3468