Bug 481069

Not being familiar with the functionality, can you take a few steps back and explain what it did, how you were using it, and also confirm that you tried to use it in Plasma 6 and were not able to (this is to make sure it didn't simply move to a place where you weren't looking for it)?

(In reply to Nate Graham from comment #1)
> Not being familiar with the functionality, can you take a few steps back and
> explain what it did, 

It allowed to trigger a command execution when specific notifications where displayed – either in combination with other notification actions or as the sole action.

> how you were using it, 

To automate system behavior upon the occurrence of events as well as to fix regressions in KDE SW (see e.g. https://bugs.kde.org/show_bug.cgi?id=481024)

> and also confirm that you tried
> to use it in Plasma 6 and were not able to (this is to make sure it didn't
> simply move to a place where you weren't looking for it)?

I can read the code and gave the relevant code repositories for reference – the functionality is gone.

In https://bugs.kde.org/show_bug.cgi?id=481068#c1 fanzhuyifan@gmail.com confirmed, that this functionality will be removed in Plasma 6.

This is a severe regression and usability degradation, breaking existing sophisticated KDE setups of long-time users like me (a quarter of a century).

If people want a crippled desktop, where the user has to serve the computer, instead of the computer serving the user, there is a large choice.

The unique selling point of KDE, as perceived in my working enviroments, is the capability of automation – if KDE removes this all over the place, it becomes dispensible.

To put it simple: you don't win a cross-country race by following the tracks of others …
Have a look at your user-base developement …

I ask because this is the first time I'm learning about the feature and I've been triaging KDE bug reports for 6 years. To my knowledge it's even the first bug report I've seen about it too. So I'm guessing whoever removed it assumed that it had no users. How exactly was this feature found and configured? How did you set it all up? What was the UX like? Etc.

(In reply to Nate Graham from comment #3)

> How exactly was this feature found and
> configured? How did you set it all up? What was the UX like? Etc.

Get a system with
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
or earlier.

Go to »system settings« -> »Notifications« -> »Application-specific settings« -> »Configure…«

There choose any application where you can »Configure Events…« – e.g. Network Management, Bluetooth, Device Notifier, KDE Mail, KMail, Calendar Reminders and many more.

If you press »Configure Events…« a configuration window pops up, where for each event you can choose any combination of »Play a sound«, »Show a message …«, »Log to file«, »Mark taskbar entry«, »RUN COMMAND«, »Speech«.

Use-cases:

* workaround fatal regressions like https://bugs.kde.org/show_bug.cgi?id=481024#c5
* detect when you are within your home WLAN and call a script doing things like hooking up to the call notification of your phone system, mounting local NAS, relaxing screen locking, home automation, …
* detecting loosing a bluetooth connection and lock screen (with timed shutdown after some time) as theft counter-measure (to protect your information) when e.g. traveling by railway
* etc.

> I ask because this is the first time I'm learning about the feature and I've
> been triaging KDE bug reports for 6 years. To my knowledge it's even the
> first bug report I've seen about it too. So I'm guessing whoever removed it
> assumed that it had no users. 

Counterquestion: how would anybody at KDE know about usage statistics of features or sophisticated use-cases?

Basing deprecation on "no bug reports" is an excellent strategy to remove things which are working flawlessly and guarantees your user base nasty surprises. I really hoped this lesson might have been learned from the disastrous KDE 3 to 4 transition …

Well, when we are at guessing – my guesses are as valid as your's:
Those removing valuable features from KDE – and I could give a very long list from the last decade … – are simply haughty enough to assume that there exists no more sophisticated usage than their unimaginative own …

Got it, thanks. I can see how that would be useful for powerful custom workflows.

(In reply to Nate Graham from comment #5)
> Got it, thanks. I can see how that would be useful for powerful custom
> workflows.

Glad to be of service.

Anyhow, my counterquestion was not rhetorical, but in earnest. I really think it worth answering, because together we have just demonstrated that a valuable and powerful feature was removed on a whim without checking its user base and its UX value:

How does KDE know which features are unused and how is removal decided?

(In reply to Flossy Cat from comment #6)
> Anyhow, my counterquestion was not rhetorical, but in earnest. I really
> think it worth answering, because together we have just demonstrated that a
> valuable and powerful feature was removed on a whim without checking its
> user base and its UX value:
> 
> How does KDE know which features are unused and how is removal decided?
We largely have no idea. It's an unfortunate side effect of our commitment to not spy on our users. It means we're in the dark about what they actually do with our software when they're not somehow making noise about it publicly. Features that get bug reports and that people are talking about in public (on social media, in our forum, in reviews of our software, etc) are features that we know people use. Other ones... well, we don't. We try not to remove stuff for no reason, but when a feature's code is old and flawed at a fundamental level and it seems like it's blocking an effort to do something new, that's when the feature is going to end up on the chopping block rather than getting fixed if no one can find anyone who uses it.

This is obviously pretty flawed but I don't know how we can do any better without turning to the dark side and spying on our users.

From the perspective of Bugzilla, this isn't a bug; the removal of the feature was intentional. The request being made here is to reconsider that removal and bring it back. Note that the "regression" keyword is already applied.

Since you've identified the commit that removed the feature, and you know C++, submitting a merge request to re-add it (including your proposed code improvements so that it doesn't get removed again) hopefully should be feasible!

I'm also using this with "spd-say" to remind me about calendar events. The notification system is not enough, korgac was much better than this small notification.

Here is the script I execute. I would be nice to get the event summary and event start, but only getting the functionality in KDE6 would be enough for a start.

cat bin/kde-alarm-event.sh
#!/bin/bash

# System Settings -> Notifications -> Application-specific settings
# Calendar Reminders -> Configure Events
# Run command: /home/asn/bin/kde-alarm-event.sh
#
# You can pass as arguments:
# %e – Event ID
# %a – Application Name
# %s – Text
# %w – WinID
# %t – window title (if it is a widget)
# %i – notification ID
# %d – Application display name
#
# None of them provide the event summary :-(

# We need to set LC_ALL or spd-say wont work!
LC_ALL=de_DE.UTF-8
export LC_ALL

/usr/bin/spd-say -l de -w "Andreas, du hast einen Termin"

(In reply to Nate Graham from comment #9)
> From the perspective of Bugzilla, this isn't a bug; the removal of the
> feature was intentional. The request being made here is to reconsider that
> removal and bring it back. Note that the "regression" keyword is already
> applied.

Yes – because I applied it …

> Since you've identified the commit that removed the feature, and you know
> C++, submitting a merge request to re-add it (including your proposed code
> improvements so that it doesn't get removed again) hopefully should be
> feasible!

The important words were "support" and "if guided", meaning:
"I do not know my way around the KDE development eco-system and need introduction and help!"
Knowing C++ alone is not sufficient to successfully navigating the re-introduction …

I also do not like the sound of "hopefully … feasible".
I'm not in dire need of opportunities to waste my time.
I'm an IT professional with a definitely non-empty schedule.

I'm willing to carve out the necessary time from my schedule only when

1. there is a commitment by KDE to re-introduce and keep this IMHO important feature, if I do a proper implementation.

2. there is introduction/help to find my way around and to quickly set up an adequate working environment – hopefully you have some kind of onboarding process for new volunteers and a mentoring system?

3. crucial technical information is provided, like
3.1 what is the time-frame for re-introducing the feature
3.2 have I identified the correct GIT (you affirmed this, thank you – but with KAlarm I identified an obsolete one …)
3.3 which library and function is to be used to retrieve specific data from the D-Bus, akonadi, or the notifier window – in the cases where I can't derive this from the code around the removed feature
(i.e. I need somebody in the know, willing to answer similar questions)

4. the same support request applies to the documentation part – if the function is not properly documented, it essentially does not exist and is not used -> back to square one …

I'm afraid I can't formally commit to that level of personal hand-holding as my time is split 500 ways and extremely limit these days. But I will be happy to assist as my time and skill levels do permit.

I can look into it once I get Plasma 6 via my distribution.

I'd like to add that this feature was one of my main reasons for switching to KDE.
A really easy way to run a command for a notification is great, and not having to faff about with custom services monitoring dbus activities.

This is a huge loss for me, being able to just quickly add a command to the lock/unlock notification from the screensaver and not have to  struggle with a service is probably the best feature of KDE.

I would like to confirm that this feature is great and I missed it on KDE 6.

I'd like to add my support for this feature being restored.  I had used it in previous version of KDE and was surprised to see it omitted in the latest release.

I've re-implemented the feature. However I need some help.

a) Is it possible to reload the libKF6notificatins.so without restarting the whole desktop?
b) I don't see an additional field in the Notifications settings: System Settings -> Notifications -> Calendar Reminders -> Alarm. Do I need to re-implement the UI part somewhere else?

I'm @asn:matrix.org in the KDE Development Matrix channel. Some pointers would be much appreciated.

https://invent.kde.org/anschneider/knotifications/-/commits/asn-notifyexecute

The UI must be separate, but I don't really know where. I can confirm that it works:

$ cat .config/kalendarac.notifyrc
[Event/alarm]
Action=Sound|Popup|Execute
Sound=/usr/share/sounds/freedesktop/stereo/bell.oga
Execute=/home/asn/bin/kde-alarm-event.sh %t

Finally, my TTS tells me which appointment I have. %t is the notification title now.

UI: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4096
Backend: https://invent.kde.org/frameworks/knotifications/-/merge_requests/143

Nice! Thanks a lot for taking this on.

Thank you!

When you are at it, kindly consider the following improvement (sample code below) (see also https://bugs.kde.org/show_bug.cgi?id=481068):

IMPROVEMENT

Add pre-filled environment variables with notification details.

RATIONALE

For anything not directly solvable with an existing program the users typically will have to script.
Providing all notification details in environment variables significantly simplifies this:
* Tighter test-loop: no need to adapt the call in the KDE UI, when other details should be used
* no need for parameter parsing

CODE (suggestion)

In »notifybyexecute.cpp« insert between
     KProcess proc;
and
     proc.setShellCommand(execLine.trimmed());
the following 

// code suggestion start
const std::string envPrefix = "KDE_NOTIFICATION_PARAMS_"; // name-space, your choice
proc.setEnv(envPrefix + "EventID", notification->eventId() ) // or any string concatenation of your choice
proc.setEnv(envPrefix + "AppName", notification->appName() )
proc.setEnv(envPrefix + "DisplayName", QGuiApplication::applicationDisplayName() )
proc.setEnv(envPrefix + "Title", notification->title() )
proc.setEnv(envPrefix + "Text", notification->text() )
// code suggestion end

Thank in advance!

I will support with end user documentation in English and German if pointed to the proper entry point.
(I consider end user documentation essential for this feature to communicate the potential.)

ERRATA
Ooops, forgot the ";" at line ends. Blush …

// code suggestion start
const std::string envPrefix = "KDE_NOTIFICATION_PARAMS_"; // name-space, your choice
proc.setEnv(envPrefix + "EventID", notification->eventId() );
proc.setEnv(envPrefix + "AppName", notification->appName() );
proc.setEnv(envPrefix + "DisplayName", QGuiApplication::applicationDisplayName() );
proc.setEnv(envPrefix + "Title", notification->title() );
proc.setEnv(envPrefix + "Text", notification->text() );
// code suggestion end

You can pass it as command line options:

https://invent.kde.org/plasma/plasma-workspace/uploads/bc3d74f4f8a25b08c05b3553e9813316/image.png

(In reply to Andreas Schneider from comment #28)
> You can pass it as command line options:

I know, but kindly read the rationale section in https://bugs.kde.org/show_bug.cgi?id=481069#c26
to see why this additional IPC mechanism is an advantage.

As initially said that this is something for power users, I think using as the command: /home/me/foo.sh %t

with foo.sh:

#!/bin/bash
TITLE=$1

echo "$TITLE"

should really not be a challenge for a power user. There is no need for option parsing if you're the only one who controls this.

If you really need all of those variables to make a decision what to do in the script. Then you're advanced enough to quickly code up option parsing in your bash script. It is a 30 line switch statement in bash. Providing the expansion on the command line allow you to use them with already existing executables.

(In reply to Andreas Schneider from comment #30)
> As initially said that this is something for power users,

I'm the initial reporter of both this bug report and https://bugs.kde.org/show_bug.cgi?id=481068
and I'm a computer SW engineer with decades of work life, contributing to FLOSS since the 80ies. 
My suggestions are not idle talk.

A real power user "does not need" this feature at all, as many use-cases can be implemented by UDEV.
Or all by "dbus-monitor" and the likes piping into a named pipe, where some script filters and triggers actions.
Both well within my scope. And both even having the advantage of being quite DE independent …

The whole point in this feature is to make advanced automation accessible to as many users as possible.
There the parallel provision of the details via environment variables improves their experience, IMHO.
Then users have both options.

The question is not, if you or I can cope, but how to make a solution accessible to a broad user base.

> …
> If you really need all of those variables to make a decision what to do in
> the script. 

Scripts develop with use – the env vars makes this less hassle.
Your approach is IMHO a deterring nightmare to document for end users … 
So few will use it and it will be dropped again soon …

> Then you're advanced enough to quickly code up option parsing in
> your bash script. It is a 30 line switch statement in bash.

A completely unnecessary hurdle …

Intimidating for new users. 
I'd prefer to encourage many users to extent their skills and DE automation,
because that gives KDE a leading edge …

> Providing the
> expansion on the command line allow you to use them with already existing
> executables.

That is well understood by me – I suggested to ADD the env vars as parallel IPC mechanism.
Doesn't cost much, avoids an additional GUI choice, eases end-users life …

But don't bother, I'll do it myself later when your change has stabilized …

it would alse be beneficial to re-add the text to speech and log to file options

I used it to

I use this feature extensively and its removal impacts my workflow significantly.

One of my primary use cases involves home automation. For example, when my computer locks, it automatically turns off my office fan and lights. Additionally, I utilize Konsole's silence notifications for long-running commands to trigger a script that sends me a Slack message when the task is completed.

While I understand there are alternative hooks and methods to achieve these actions, leveraging the notification system has been the most straightforward and effective approach for me. It also enables my computer to alert me about low disk space and other easy-to-configure notifications.

Removing this feature would disrupt these automations, and I'd like to advocate for its retention or for a similar functionality to be made available.

affecting me as well and it really hurts to be honest. doing several tasks when locking/unlocking my screen so would really appreciate getting this back..

for whom this function is also sorely missed: I stumbled over a workaround which works pretty well (for me):
https://www.baeldung.com/linux/run-script-session-locked-unlocked

while this is not a fix for this issue it at least let me do what I need until this bug is resolved.. I still think it would be great having the functionality back as it was in Plasma < 6.

TL;DR
add the following in the autostart of your display manager (here KDE obviously) and adjust it ofc.
(if it does not work read that article as the dbus command might is different or changed etc)


#!/bin/bash
#####################################################################
#
# run actions when screen locks/unlocks
#
# source:
#  https://www.baeldung.com/linux/run-script-session-locked-unlocked
#
#####################################################################

while read line 
do
    case "$line" in
        *"{'LockedHint': <true>}"*) # screen locked
            true # replace with something meaningful ;)
        ;;
        *"{'LockedHint': <false>}"*) # screen unlocked
            ~/scripts/kpxc-unlock.sh; notify-send -a "Screen unlocked" -i keepassxc -t 3000 "KeepassX unlock triggered"
        ;;
    esac
done < <(gdbus monitor -y -d org.freedesktop.login1)

Hi, 
affecting me as well and it really hurts to be honest. doing several tasks and make my computer fully associed with domotic is very important.
Please consider to réintegrate this feature and never remove feature without a full consent of Users.
This is the most reason when user are quiting software or system
Thanks

The merge request has been closed :-(

https://invent.kde.org/frameworks/knotifications/-/merge_requests/143

I apologize for not contributing much to the discussion, but I was also hoping for a satisfactory resolution to the issue.
I started using KDE a few months before the Plasma 6 release and found the notifications feature very useful for adding extra automation and features. I was looking forward to expanding its use even more.
Since updating to Plasma 6, I’ve seen some automations others have implemented that I wanted to try as soon as the feature was re-added. Everything seemed promising, with someone already working on it, but now I can’t quite understand why it hasn’t been merged.

My Disappointment Is Immeasurable And My Day Is Ruined.

ps. Don't take this too harshly, KDE is still a great DE; feature rich and latest updates has been making it more stable and fixed lot of bugs, the team is doing a great job... I'm just going to miss such a handy feature, a lot.

Created attachment 174284 [details]
attachment-3147338-0.html

I desperately need this feature back, because my entire room is automated by my notification triggered commands, (IE, flash lights when  on error or turn on fan for 5 minutes on unlock) 

"I guess the lesson to take away from this is to never become reliant on any KDE feature because someone might rip it out on a whim for not being the theoretically perfect implementation, even if it doesn't cause any problems in its current state."

EXACTLY.


"Which – in the light of the other bugs and regressions reported by me 
— at least for me shortens to: 'Never rely on KDE anymore.' "

Unfortunately so…


"A single person blocks the repair of a regression against the expressed wishes and well-founded use-cases of numerous users and several developers advocating the repair. IMHO Open Source Software is commons (in the sense of the original agricultural concept) and such despotic ruling of a single person over the wishes and needs of many is not acceptable."

Very true, I cannot even begin to describe how betrayed I felt when this feature was removed. This is completely unnacceptable.


For me, this is probably one of my most used KDE features, I used it for everything from automating to audio cues to changing my theme and window styling when I launch games. I don’t like the direction KDE has been going with all these removals lately, and there is no telling what they might do next. I want to support and praise the developers, but it is hard to do so when my most beloved features are being ruthlessly ripped away from me.

I did see in the commit logs on Invent, that it may be getting re-added but who knows when that will happen. Since it was promised to be re-added in 6.1, but never made it into the update, maybe I will spin up an Arch Linux .ISO to see if it got re-added.


> On Oct 1, 2024, at 8:53 AM, Flossy Cat <bugzilla_noreply@kde.org> wrote:
> 
> https://bugs.kde.org/show_bug.cgi?id=481069
> 
> --- Comment #39 from Flossy Cat <[removed]> ---
> (In reply to Andreas Schneider from comment #38)
>> The merge request has been closed :-(
>> 
>> https://invent.kde.org/frameworks/knotifications/-/merge_requests/143
> 
> Thank you for the information – and thank you very much for your spirited
> effort to re-establish that valuable functionality.
> 
> As "the dunce" had so nicely put it in the "invent" discussion thread:
> 
> "I guess the lesson to take away from this is to never become reliant on any
> KDE feature because someone might rip it out on a whim for not being the
> theoretically perfect implementation, even if it doesn't cause any problems in
> its current state."
> 
> Which – in the light of the other bugs and regressions reported by me – at
> least for me shortens to:
> "Never rely on KDE anymore." 
> 
> A single person blocks the repair of a regression against the expressed wishes
> and well-founded use-cases of numerous users and several developers advocating
> the repair. IMHO Open Source Software is commons (in the sense of the original
> agricultural concept) and such despotic ruling of a single person over the
> wishes and needs of many is not acceptable.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

.. for me the most annoying part was:

> Christoph Cullmann
> August 30, 2024 at 7:41:45 PM GMT+2
> @davidedmundson & @ngraham: either we now agree that this is not wanted and close it or one thinks again what to do with it.

.. then.. exactly 4(!!!) minutes later:

> David Edmundson closed August 30, 2024 at 7:45:45 PM GMT+2

no reason. no explanation why this decision was taken. just like shut up guys, you want it? we don't care

that is not a good manner imho.

-

I've been patiently waiting with every KDE update for the return of this functionality. What a terrible, misguided decision.

Is there a reason it's David who gets to decide this? Idk how this works.

> Idk how this works.

In KDE, any contributor can raise concern about any part of the code. David rightfully wrote that the notification server is the correct place to execute external applications, instead of the client process that issued the notification. No other contributor objected, so it is perfectly OK that David rejected the patch in the current form.

(In reply to Christoph Feck from comment #47)
> > Idk how this works.
> 
> In KDE, any contributor can raise concern about any part of the code. David
> rightfully wrote that the notification server is the correct place to
> execute external applications, instead of the client process that issued the
> notification. No other contributor objected, so it is perfectly OK that
> David rejected the patch in the current form.

Wouldn’t it be better to merge this as it is and replace it with a better alternative once it’s ready, rather than leaving it in limbo for who knows how long?
Doesn't seem to cause issues or performance problems, there's no technical issues aside from "this would be better here instead of there", it's already ready and it's based on code that worked well during, afaik, quite a long time and is not even that much code.

I don't know if everyone knows this feature works as expected in kde plasma on the latest stable of Ubuntu or at least it does for me.

(In reply to Zach Robichaud from comment #51)
> I don't know if everyone knows this feature works as expected in kde plasma
> on the latest stable of Ubuntu or at least it does for me.

Probably they are still using Plasma 5.27.xx, this issue is for plasma 6

(In reply to Christoph Feck from comment #47)
> > Idk how this works.
> 
> In KDE, any contributor can raise concern about any part of the code. David
> rightfully wrote that the notification server is the correct place to
> execute external applications, instead of the client process that issued the
> notification. No other contributor objected, so it is perfectly OK that
> David rejected the patch in the current form.

If someone spends time to implement something and it is the wrong place, shouldn't you explain where it should be implemented and why and give some pointers instead of closing it without comment?

This how you drive contributors *away*.

(In reply to Andreas Schneider from comment #53)
> (In reply to Christoph Feck from comment #47)
> > > Idk how this works.
> > 
> > In KDE, any contributor can raise concern about any part of the code. David
> > rightfully wrote that the notification server is the correct place to
> > execute external applications, instead of the client process that issued the
> > notification. No other contributor objected, so it is perfectly OK that
> > David rejected the patch in the current form.
> 
> If someone spends time to implement something and it is the wrong place,
> shouldn't you explain where it should be implemented and why and give some
> pointers instead of closing it without comment?
> 
> This how you drive contributors *away*.

a) What is the notification server?
b) Where is the source code of the notification server?
c) Why is "Play a sound" not implemented in the notification server?

I too would like this feature to be re-implemented and I don't understand why the PR is not merged in its current form and simply improved upon down the line. I don't understand why David Edmundson simply rejected it and nobody is doing anything about it. Even if it's "too niche", it is a valid usecase, and a feature that existed before that was taken for no good reason.

Currently, one of the reasons I want this feature is to fix the notification badge of Vesktop that is broken on KDE Plasma 6 using the method described here: https://github.com/Vencord/Vesktop/issues/298#issuecomment-2132234058

Adding another voice to the growing "arbitrary and unannounced removal of features breaks my workflow" choir. While this is a papercut I can patch over on my bleeding-edge tinderbox desktop, it's a hard blocker to me moving any systems I rely on to work over to plasma 6.

It is telling that discovering the cause for such regressions usually requires digging through bug reports and commits, and doing so often reveals comments to the tune of "This is niche / I don't understand the use case / I don't like how it's implemented, so let's just remove it and see if anybody notices"... 
Swiftly followed by somebody noticing, at which point a laundry-list of trivial and/or tangential objections is raised to block attempts at getting the initial decision reverted or functionality reimplemented.

This feature wasn't broken and it wasn't generating friction for users or excessive bug reports. Rather it was removed because the contributor involved wasn't using it and felt it was "conceptually wrong".
We have a PR, one which works as intended and which Andreas put considerable effort into. Please merge it, and if "conceptual" changes are required (with strong arguments and practical examples for such) down the line, implement them in such a way as to retain feature-parity.


I thought KDE was, at least to some extent, a community effort. Please listen to your community and your users. 
Especially listen to your experienced power-users, because they are the people most likely to and capable of engaging in reasoned discussion, useful bug reports, and usable code contributions.

I use a OLED television as a monitor, and unfortunately, TVs do not automatically "turn off" when they lose signal, like monitors do. I created a small program that sends a "power off" signal to my TV through its API, and used this feature to execute my program on logout.

Since Debian SID updated to Plasma 6, this is the only big problem I am facing.

We also rely considerably on the "run command" feature (used for screensaver) at all our workstations.
I understand to remove not correct implemented features, but I hope some creative genius will find the right way to implement.
Thanks for your effort.