~kennylevinsen/poweralertd#1: 
Ability to filter out notifications

Hey Kenny,

Thanks for creating this nice tool!

Would you be interested to implement some way to filter which notifications to show and which to skip?

I'm thinking about both filters on devices and filters on specific events.

For example, I personally am only interested in "Power level low / critical" events, but I can imagine other people will have different needs.

-- Maxim Baz

Status
REPORTED
Submitter
Maxim Baz
Assigned to
No-one
Submitted
4 years ago
Updated
a month ago
Labels
feature

~kennylevinsen 4 years ago

What events are you getting that are "too much"? At least for me, the events I get seem pretty minimal.

Maxim Baz 4 years ago ยท edit

Personally, I'm only interested in "Power level low / critical", all other events such as "Power supply online / offline", "Battery charging / discharging - current level XX" have no value for me and only distract me.

~tardypad 3 years ago

I'd be interested in this feature for the exact same use case as mentioned in the previous comment.

~anarcat 8 months ago

i have the same problem: my framework laptop charges to 100% then poweralertd notifies me it's discharging... then charging... then discharging...

I would paste the output of the program, but I just realized it doesn't have any, which is kind of a shame. It would be nice if it would copy to stderr what it shows in the notification area for debugging / history tracking...

it looks like https://lists.sr.ht/~kennylevinsen/poweralertd-devel/patches/43895 tries to address this, at least...

~anarcat a month ago

Hi!

This is kind of a dealbreaker for me. I'm patching this locally in the Debian package and I have submitted the aforementioned patch to the Debian bug report as well, so I'm wondering if there's a plan for this. :)

~tardypad a month ago

Those update notifications are annoying for me too. In case your notification daemon supports it, you can filter them out since commit Include category with notification

For example with mako, you can put this in your config.

[category="power.update"]
invisible=1

But to me this is still just a workaround though. It would be better to prevent the notifications from being triggered in the first place. For example in my system, the notifications are still cluttering the history even if they don't get displayed.

~tardypad a month ago

~kennylevinsen if I find the time to work on this, would be open to accept the addition of another flag like -c device.removed -c power.critical that can be used several times to list the categories we want to be notified about?

~anarcat a month ago

i actually want to have charge/discharge notifications, i just don't want them flapping they way they currently do...

So redacting out notification categories doesn't fix this issue for me, what does fix it is limiting the notifications pass a certain threshold. Ideally, we'd do some hysteresis here to be more clever about this, but that's a tad more complicated to implement.

Honestly, at this point, if we could just merge patch 43895 it would fix it all for me...

~tardypad a month ago

I see but I'd say then this is a separate issue than what was originally mentioned here

~anarcat a month ago

true! maybe i should just file another issue. :)

~kennylevinsen a month ago

~anarcat, I asked on that patch about the exact messages, as collected with upower --monitor-detail or sudo busctl monitor, so that I could understand what exactly it is we want to silence.

~tardypad, doing it on notification category has the caveat that any of the warnings also depend on power.cleared to undo them cleanly, which would then need to be ignored if the previous state was a muted state to not cause confusing clear messages. Instead, you probably want to pick which event categories (state, warning, online) to process.

Configuring notifications behavior on the mako side is not really a workaround though.

~anarcat a month ago

oh, interesting, i didn't realize the patch was waiting for info, i'll try to figure that out!

Register here or Log in to comment, or comment via email.