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.

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

Some technicalities: 

You set this bug report as "wish list", but it is NOT a FEATURE REQUEST.
It is about a REGRESSION, breaking existing usage and use-cases – as we discussed.

Further the related bug report https://bugs.kde.org/show_bug.cgi?id=481068 is about an actually buggy (incomplete) implementation.

If the REGRESSION is avoided by not removing the feature, the code handling the %-escapes needs fixing.

Further the code should be improved by providing better provision of the notification information to the executed process.
I suggest generally providing all information via 
* environment variables to the called process in the likeness of »KDE_notifier_cmd_«_"PARAMETER" where parameter is "Title", "WinID", etc.
* STDIN – simply the complete visible text in the notification window, perhaps amended with additional info available (a "key=value" version is already provided by the environment variables)

I consider it much simpler to provide all these parameter passing in parallel than have a GUI component for selection.

Finally the functionality NEEDS to be documented: KDE can't expect widespread use (or even discovery) of functionality like this, if there is no documentation …

I can easily support in doing
1. tests
2. the English and German documentation

I can support with coding if guided (I know C++ well enough, but not the KDE libraries).

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