Bug 481068

Summary:	The power to run a command upon a notification is severely limited by lack of information
Product:	[Frameworks and Libraries] frameworks-knotifications	Reporter:	Unknown <null>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	dion, fanzhuyifan, kdelibs-bugs-null, pfmiller
Priority:	NOR
Version First Reported In:	5.103.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=481069
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Unknown 2024-02-08 17:36:10 UTC

SUMMARY
While it is possible to trigger a command execution for specific event types, these commands do not have all available information from the triggering notification event, severely limiting the possibility of the programmatic response and thus the use-cases (of course the content of a specific notification is controlled by some other piece of SW – but it is a serious flaw of the notification system to not convey all available information!)

Consider providing all information by actually providing the title of the notification – %t is not set currently!
Alternatively or additionally consider to provide all information in a structured format (name=value / JSON / XML) on
STDIN of the executed command or as an environment variable (there several formats could be provided in different variables).

STEPS TO REPRODUCE
1. edit in system settings a notification type to contain a command
2. verify the data provided to it (see https://invent.kde.org/frameworks/knotifications/-/blob/kf5/src/notifybyexecute.cpp?ref_type=heads) and the discussion in response to comment 2 of (https://bugs.kde.org/show_bug.cgi?id=481024)

OBSERVED RESULT
Insufficient information of the triggering notification is available to the command.

EXPECTED RESULT
All information pertaining to the triggering notification should be available to the command to allow optimal programmatic response.

SOFTWARE/OS VERSIONS
SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
As a seasoned computer engineer I might help with changes if brought up to speed …

Comment 1 fanzhuyifan 2024-02-09 17:27:26 UTC

Support for notifybyexecute was dropped in https://invent.kde.org/frameworks/knotifications/-/merge_requests/92, so marking this as unmaintained

Comment 2 Unknown 2024-02-09 18:07:16 UTC

My bug report demonstrates there is user request for this feature and the decision is contended: 
https://bugs.kde.org/show_bug.cgi?id=481069

These solitary declarations of unmaintenance show a lack of respect for longterm KDE users who
used the (former) powers of KDE to set up sophisticated work environments.
This was the hallmark and unique selling point of KDE – without it you will loose further user base …

I consider this very unwise – both in general and in this specific case.

Comment 3 fanzhuyifan 2024-02-09 18:14:56 UTC

(In reply to Flossy Cat from comment #2)
> My bug report demonstrates there is user request for this feature and the
> decision is contended: 
> https://bugs.kde.org/show_bug.cgi?id=481069
> 
> These solitary declarations of unmaintenance show a lack of respect for
> longterm KDE users who
> used the (former) powers of KDE to set up sophisticated work environments.
> This was the hallmark and unique selling point of KDE – without it you will
> loose further user base …
> 
> I consider this very unwise – both in general and in this specific case.

How about let's consolidate the discussion on resupporting this in 481069? (That's why I cc'ed 481069 when I closed this report.) We can always reopen if we decide to resupport this.

Comment 4 Unknown 2024-02-10 08:50:52 UTC

(In reply to fanzhuyifan from comment #3)
> How about let's consolidate the discussion on resupporting this in 481069?
> (That's why I cc'ed 481069 when I closed this report.) We can always reopen
> if we decide to resupport this.

That sound much more respectful than closing the issue without a word of explanation.

Let's go.