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 …
Support for notifybyexecute was dropped in https://invent.kde.org/frameworks/knotifications/-/merge_requests/92, so marking this as unmaintained
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.
(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.
(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.