Using KDE, can I configure the GUI notifications to get saved in the KDE notification-history by the system-tray? (rather than just disappearing)

[dwawlyn]

I just installed nohang per these instructions:
https://github.com/hakavlad/nohang/?tab=readme-ov-file#to-install-on-ubuntu-20042010
(ie using sudo systemctl enable --now nohang-desktop.service, rather than with nohang.service)

and I tested it and it worked perfectly
(I triggered a firefox memory leak that used to freeze up my system, but this time it just killed firefox instead of freezing -- very happy to finally get that fixed!)

The one thing I'd like to improve is:

I'm using KDE, and I'd like to configure the GUI notifications to get saved in the KDE notification-history by the system-tray.
(ie, in my test, the GUI notifications popped up, but then they just disappeared after)

Is there something I could simply tweak in a config file somewhere?
(Or is it something that should already be working, and I should ask the KDE people about it as a bug...?)

I looked through section 4. Warnings and notifications in the file /etc/nohang/nohang-desktop.conf,
but I couldn't spot anything relevant...

[

Operating System:      	TUXEDO OS 3 (based on Ubuntu 22.04.5)
KDE Plasma Version:    	6.1.5
KDE Frameworks Version:	6.5.0
Qt Version:            	6.7.2
Kernel Version:        	6.11.0-102007-tuxedo (64-bit)
Graphics Platform:     	X11

]

[hakavlad]

Maybe related: rfjakob/earlyoom#139

I assume that saving notifications is handled by the desktop environment and nohang can't help with that.

[hakavlad]

Also #79 (comment)

[dwawlyn]

Thanks for the links!

It seems that it indeed works to just make the tweak in the KDE settings GUI
(
ie, I did:
Notifications -> Application Settings [top right currently] -> Other Applications -> checkbox select "Show in history"

And I'll have to ask the KDE people later if that turns out to have annoying side-effects,
or interacts weirdly with the "Shown when relevant" default setting for "notifications" as a system-tray entry...
)

But yeah, I just tested it using nohang --memload, and yup, the notifications ended up in the history by system-tray

---

That being said...

I assume that saving notifications is handled by the desktop environment and nohang can't help with that.

Well, yes, unless for instance it was simply a matter of nohang passing the correct flags to whatever program it calls to do the notifications (notify-send?)
(like, flags to mark the notifications as being a particular "type" or level of urgency or something?)
in which case it could well have been a matter of tweaking something in a config file, ya know?

... actually, it seems that the notifications sent by nohang do not use "urgency critical" flag
(eg notify-send "test critical" -u critical, again assuming it does use notify-send by defaultt?)

Is it possible for me to make it use the -u critical flag by just tweaking something in a config?
Or would I have to dig into the code...?

---

... btw, yeah, in this doc:
https://galago-project.org/specs/notification/0.9/notification-spec-0.9.txt

It seems like the different "types" aren't really relevant
(they're meant for stuff like "device connections"/"file transfers"/"email"/"network status"/etc)

but the "urgency levels" do seem relevant...

It says:

For low and normal urgencies,
server implementations may display the notifications how they choose.
They should, however, have a sane expiration timeout dependent on the urgency level.

(So like, "low" and "normal" notifications are are expected to disappear from the screen)

But then it says:

Critical notifications should not automatically expire,
as they are things that the user will most likely want to know about.
They should only be closed when the user dismisses them, for example, by clicking on the notification.

Which sounds like it should maybe be the default for something like a memory leak causing something to be killed?
(Like, regardless of what desktop environment someone is using.)