SUMMARY Some messengers allow deleting messages, and as part of that they nuke the relevant notifications. The idea is understandable, that once a message got deleted the notifications kind of gets "orphaned", so it makes sense to remove it as well. However, in practice, I personally find it interesting to see the message I was sent, even if it's no more. In Android there is a "notifications history" that includes deleted notifications. I'd like to see similar functionality on KDE, whether opt-in or opt-out. STEPS TO REPRODUCE 1. Open Telegram and unfocus it 2. Ask someone to send a message while you have TG unfocused 3. Once KDE notification appears, ask the person to delete the message 4. Look at the KDE notifications history OBSERVED RESULT You won't find notification about that message EXPECTED RESULT You'll find it there, ideally with a mark that it was "deleted" SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2
It's an interesting idea, but I'm afraid this doesn't really work with how the FreeDesktop notification spec governs things, sorry.
(In reply to Nate Graham from comment #1) > It's an interesting idea, but I'm afraid this doesn't really work with how > the FreeDesktop notification spec governs things, sorry. Does it have a requirement that "deleted notifications" are truly deleted? Why can't we have a checkbox to behave differently compared to what specification says?
(In reply to Konstantin Kharlamov from comment #2) > (In reply to Nate Graham from comment #1) > > It's an interesting idea, but I'm afraid this doesn't really work with how > > the FreeDesktop notification spec governs things, sorry. > > Does it have a requirement that "deleted notifications" are truly deleted? > Why can't we have a checkbox to behave differently compared to what > specification says? @Nate ping. I just realized the issue is closed, would be great to reopen it if possible because the current situation with notifications I'd say isn't perfect…
No, sorry.
But why? Sorry if I'm wrong, but thus far this looks more like your personal decision. Which is okay of course because you're the maintainer, but then please state this explicitly instead of vaguely referring to some standards.
@Nate ping
I'm passing on what I very strongly suspect the notifications maintainer will tell you, based on prior opinions. If he shows up here and has a different opinion, then we can reconsider it.
Thank you for clarification! Can I ping the maintainer up somewhere, e.g. on Matrix or whatnot, to hear their opinion?
Maybe, but jeep in mind there's a fine line between being inquisitive and being annoying.
(In reply to Nate Graham from comment #9) > (In reply to Konstantin Kharlamov from comment #8) > > Thank you for clarification! Can I ping the maintainer up somewhere, e.g. on > > Matrix or whatnot, to hear their opinion? > Maybe, but jeep in mind there's a fine line between being inquisitive and > being annoying. This is getting weird… Did you genuinely read it as an ask for permission to talk to a person? Sorry if that's so, I meant to ask how could I contact them because I have no idea who is the maintainer. In any case, Nate, barring the last odd reply you answered zero of my questions, and in this context your poke at me being "annoying" doesn't look good. I always saw you as a technical person, I loved your blog posts. It is very surprising to communicate to you here and find that not only you can't be specific, but it feels like you're trying to get rid of me by hinting I am being annoying, even though it was you who 1. Closed the report with a spec reference which I suspect more and more isn't an issue, 2. Keep being vague.
I'd kindly point out that… well, people sometimes misread, things happen… And if you want so I am open to just recreate the report with no reference to this one and we can forget this whole discussion has ever happened…
Sorry, you're encountering me in bug triaging mode, and I'm trying to get through a large list of bugs as quickly as possible. In this case, I've identified that this bug report is a feature request that is very unlikely to be implemented for various reasons, and so I've decided to close it to avoid it staying open on bugs.kde.org, simultaneously giving you false hope and making our bug metrics look worse. It's possible I've mis-triaged this and there is some hope if the requested feature eventually getting implemented. You are of course welcome to contact the maintainer to see what he thinks (he's the other person besides me in the CC list). If he's receptive to the idea, we can re-open this.