[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Zach Robichaud changed: What|Removed |Added CC||zach2...@gmail.com --- Comment #34 from Zach Robichaud --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Pavel Dobiáš changed: What|Removed |Added CC||pavel23...@proton.me -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 bugskdeorg.20.net...@spamgourmet.com changed: What|Removed |Added CC||bugskdeorg.20.nettle@spamgo ||urmet.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Oded Arbel changed: What|Removed |Added CC||o...@geek.co.il -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 gudvinr+...@gmail.com changed: What|Removed |Added CC||gudvinr+...@gmail.com --- Comment #33 from gudvinr+...@gmail.com --- I used it to -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 usr_40476 changed: What|Removed |Added CC||usr_40...@icloud.com --- Comment #32 from usr_40476 --- it would alse be beneficial to re-add the text to speech and log to file options -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #31 from Flossy Cat --- (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 … -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #30 from Andreas Schneider --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #29 from Flossy Cat --- (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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #28 from Andreas Schneider --- You can pass it as command line options: https://invent.kde.org/plasma/plasma-workspace/uploads/bc3d74f4f8a25b08c05b3553e9813316/image.png -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #27 from Flossy Cat --- 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 are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #26 from Flossy Cat --- 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.) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #25 from Nate Graham --- Nice! Thanks a lot for taking this on. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Andreas Schneider changed: What|Removed |Added Assignee|kdelibs-b...@kde.org|a...@cryptomilk.org Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #24 from Andreas Schneider --- UI: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4096 Backend: https://invent.kde.org/frameworks/knotifications/-/merge_requests/143 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Jure Repinc changed: What|Removed |Added CC||j...@holodeck1.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #23 from Andreas Schneider --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #22 from Andreas Schneider --- 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 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #21 from Nate Graham --- Probably because they're not productively related to getting this feature re-implemented now that there's a bugzilla ticket open for it. If you'd like to discuss other matters, the place to do it is elsewhere (https://discuss.kde.org is probably a decent place to start). Doing it here will just annoy all the people CCd on this bugzilla ticket and make everyone involved less likely to want to work on it. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #20 from Flossy Cat --- My comments #18 and #19 were classified as spam – can somebody enlighten me, why? And remove this classification because I am actually trying to achieve some progress here. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #19 from Flossy Cat --- (In reply to Nate Graham from comment #7) > (In reply to Flossy Cat from comment #6) > > … > > How does KDE know which features are unused and how is removal decided? > We largely have no idea. The reactions of users in this discussion clearly show, how ill advised the removal of this feature was. This clearly demonstrate a serious bug in the KDE decision processes. Further your answer in comment #13 demonstrates more crucial bugs: There seems no onboarding process for new volunteers, no mentoring, not even introductive documentation … Where to discuss this bugs and proposals for solution? > 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. I'm not as pessimistic, but this is not the proper place to propose solutions … -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #18 from Flossy Cat --- (In reply to Nate Graham from comment #13) > 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. Thank you for your generous offer and sorry for my delay: The "new KDE version" coming with OpenSuSE 15.5 seems to be one of those notorious "devastating improvements". The newest unwanted "entertainment" soaking up all spare time during the last weeks: https://bugs.kde.org/show_bug.cgi?id=483545 The further reactions to this discussion show clearly: The decision to remove this feature was very ill advised. Before coming back to your generous support offer and going into technicalities, I really think it necessary that those people responsible for this decision look into this discussion and commit themselves into keeping these functionality if we re-implement it. Otherwise we risk wasting our time, when in the end somebody does not accept the commit on the ground of "the lowest denominator of supported platforms determines what power KDE is allowed to have" or some similar -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 benbry...@gmail.com changed: What|Removed |Added CC||benbry...@gmail.com --- Comment #17 from benbry...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #16 from Eric Hartmann --- I would like to confirm that this feature is great and I missed it on KDE 6. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Eric Hartmann changed: What|Removed |Added CC||hartmann.e...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 g...@orzfly.com changed: What|Removed |Added CC||g...@orzfly.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 vodka changed: What|Removed |Added CC||vodka...@gmail.com --- Comment #15 from vodka --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Sdar changed: What|Removed |Added CC||s...@vivaldi.net -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Dashon changed: What|Removed |Added CC||dashonww...@pm.me -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #14 from Andreas Schneider --- I can look into it once I get Plasma 6 via my distribution. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #13 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #12 from Flossy Cat --- (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 … -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #11 from Andreas Schneider --- 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" -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Andreas Schneider changed: What|Removed |Added CC||a...@cryptomilk.org --- Comment #10 from Andreas Schneider --- 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #9 from Nate Graham --- >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! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Flossy Cat changed: What|Removed |Added Keywords||regression, usability --- Comment #8 from Flossy Cat --- (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). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #7 from Nate Graham --- (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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 --- Comment #6 from Flossy Cat --- (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? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Nate Graham changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Severity|grave |wishlist Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 CC||nicolas.fe...@gmx.de Summary|With framework version 6|Consider re-adding the |the option to execute |feature to execute commands |commands as part of |in notifications |notifications seems gone| --- Comment #5 from Nate Graham --- Got it, thanks. I can see how that would be useful for powerful custom workflows. -- You are receiving this mail because: You are watching all bug changes.
