FOR CONTEXT I'm using the KDE PIM tools since well over two decades when there was no integration into kontact. Thus, when I write "hard show-stopper" this is no lighthearted whim. The functional regression is so disruptive to decade-old workflows that I definitely – to my utmost regret – will have to switch to Thunderbird (providing sufficient snoozing and other functionality) within a short time-frame, when neither solution or work-around is available. Because of the effort involved, this migration will be permanent. SUMMARY With the upgrade from openSuSE 15.4 to 15.5 and thus to the mentioned SW versions reminders for calendar events or tasks are only notified via KDE notifications, with fixed snooze options of 5 minutes and 1 hour. This is a catastrophic regression – consider work-flows like the following: Sample workflow: Every year in mid October a reminder to empty the rain barrels is needed to prevent damage by freezing. When the reminder comes up, long-term weather forecast are checked and the reminder postponed accordingly (last year in several steps until December – making good use of the water …) It is no option to change the reminder timing in the issue itself, because the timing should be preserved for the next year. The delays only apply to the current reminder … I have many analogous workflow in the areas of taxes, technical inspections, medical examinations, vaccinations, … STEPS TO REPRODUCE 1. Create a calendar event with reminder in the very near future. 2. Watch the notification. OBSERVED RESULT KDE notification popup with only 2 fixed delays (5 min, 1 hour). EXPECTED RESULT An option to configure a user-choosen delay. POSSIBLE DUPLICATES I judge the following Bug-IDs (in part older than one year!) addressing the same problem – but neither do I see solutions, workarounds nor progress: 457046 452264 453298 453299 457046 461233 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 I'm a computer engineer and willing and capable of contributing to a solution if brought up to speed by some guidance. (e.g. around 2003 I contributed to the PDA integration and syncing …)
SEARCH FOR A WORKAROUND Within this comment thread I suggest to collect the discussion about workarounds.
Possible Workaround: »kalarm« ========================== »kalarm« provides all the necessary functionality to set and postpone alarms (and even some useful additional functionality). The burning question remains, how to call »kalarm« or create »kalarm« reminders from »korganizer« reminder events. Usage of »kalarm« is quite simple – 3 useful variants exist (a matter of personal preference): »kalarm -b --edit-new-display -n "Test kalarm" -t 14:50 "Test notification via kalarm"« Opens a window to edit the alarm and change various details, the time, etc. »kalarm -b -n "Test kalarm" -t 14:50 "Test notification via kalarm"« This will immediately set and trigger an alarm at the given time (which has to be slightly in the future). The alarm is presented in a separate window, providing a button, opening a window for flexible snooze options. »kalarm -N -b -n "Test kalarm" -t 14:50 "Test notification via kalarm"« This will immediately set and trigger an alarm as above, but because of »-N« the alarm is presented as notification, providing a button, opening a window for flexible snooze options. (»-N« can be used in the »--edit-new-display« too, to preselect notification as method). (In all variants there is a annoying bug in handling the parameters: https://bugs.kde.org/show_bug.cgi?id=481053)
VIA KORGANIZER (In reply to Flossy Cat from comment #2) > Possible Workaround: »kalarm« > ========================== > … > The burning question remains, how to call »kalarm« or create »kalarm« > reminders from »korganizer« reminder events. AFAIR there once was an option within »korganizer« – even if not I see valuable use-cases besides this workaround topic. You might care to support and comment on the feature request: https://bugs.kde.org/show_bug.cgi?id=481063
I was told this was because freedesktop.org notifications don't support custom widgets, only a few action buttons, for interoperability with other desktop environments. I agree however this is really suboptimal, especially when not caring for other desktop environments. As for "workarounds", you can find the code in akonadi-calendar/reminder-daemon/alarmnotification.cpp line 135 and add more buttons like "remind tomorrow". Maybe we should implement an alternative notification solution in kalendarac that looks more like the old korgac dialog (minus its bugs...).
VIA KNOTIFIER (In reply to Flossy Cat from comment #2) > Possible Workaround: »kalarm« > ========================== > … > The burning question remains, how to call »kalarm« or create »kalarm« > reminders from »korganizer« reminder events. The notification demon (at least »knotifier«) allows (still – see below) to trigger a command with a notification. To usefully trigger a »kalarm« workaround we'd need sufficient information to construct a new reminder. I tested for * arguments – the command triggered receives no data via arguments added to the call * enviroment – the command triggered receives no data via environment variables * STDIN – the command triggered receives no data via its STDIN file descriptor Finally I tested for %-escaped variables and found the following: (https://invent.kde.org/frameworks/knotifications/-/blob/kf5/src/notifybyexecute.cpp?ref_type=heads) %e – Event ID %a – Application Name %s – text of the notification %w – WinID %t – window title %i – notification ID %d – Application display name For the event in the attached screenshot this yields EventID(%e)=»alarm« AppName(%a)=»kalendarac« Text(%t)=»Aufgabe hat um 16:32 begonnen« NotificationID(%i)=»10« DisplayName(%d)=»Erinnerungen« WindowTitle(%t)=»%t« – obviously this variable is not expanded? WinID(%w)=»0« – effectively no windowID returned As can be seen from the screenshot – essential information is not provided. :-( There is much room for improvement to make the option of programmatic notifications useful – if you share this sentiment you might care to comment on https://bugs.kde.org/show_bug.cgi?id=481068 Further, judging from the code, the option of executing commands as part of a notification will be removed in KF6: »notifybyexecute« is missing in https://invent.kde.org/frameworks/knotifications/-/tree/master/src?ref_type=heads I strongly object to this further usability-degradation – you might want to join that cause: https://bugs.kde.org/show_bug.cgi?id=481069 Further I tested the option to write notification data to a file (which could of course be a suitably hooked-up socket): This just yields »- KNotify Mi. Feb. 7 16:54:01 2024: Aufgabe hat um 16:32 begonnen« for the event above – again not useful as essential information is missing and even less useful than the %-escapes! Because of this short-comings this approach is alas not viable (as isn't "via »korganizer«") …
Created attachment 165676 [details] Screenshot of a notifier popup This screenshot of a notifier popup serves for comparison with the information provided to "execute command" hooks in comment #5
Comment on attachment 165676 [details] Screenshot of a notifier popup This screenshots serves as comparison to the information actually provided via the "execute command" hook – see comment #5
(In reply to David Faure from comment #4) > I was told this was because freedesktop.org notifications don't support > custom widgets, only a few action buttons, for interoperability with other > desktop environments. I know – but this only demonstrates the choice to move to "freedesktop.org notifications" as sole solution was ill-advided. > I agree however this is really suboptimal, especially when not caring for other desktop environments. "really suboptimal" is runner-up for the euphemism of the week … IMHO it is a fundamental lack of respect and rude to long-term KDE users to fundamentally break existing functionality (and their workflows) without proper announcement and transition provisions. The fatal decision happened around 2 years ago, complaints exist since more than 18 month – without solution. I was confronted with this breaking changes when non-suspecting upgrading my distribution – and the heart-ripping decision to give up a quarter of a century KDE PIM usage, if I do not find a working workaround within 2–3 weeks. (And that is not the first incident of this time – but so far definitely the worst and potentially final one.) IMHO the proper way would have been to keep the old behavior as an option and wait for the reaction for at least 2 years before cutting of the old functionality. > As for "workarounds", you can find the code in > akonadi-calendar/reminder-daemon/alarmnotification.cpp line 135 and add more > buttons like "remind tomorrow". The number of buttons is limited and cannot provide for my variable needs, lest the needs of the numerous others having raised similar complaints. This is *not a viable workaround*. Are there any D-Bus-events I could hook on? > Maybe we should implement an alternative notification solution in kalendarac > that looks more like the old korgac dialog (minus its bugs...). Definitely. And very soon. Actually you should never have removed the original functionality without a substitute or a transition strategy as lined out above.
> Actually you should never have removed the original functionality "You"? Just because I have a @kde.org address does not mean I was part of that decision in any shape of form. On the contrary I was among the first ones to complain about it when I found out, as a user. And I'm writing here because I'm on the same side as you, trying to find possible solutions. I know you're frustrated but please refrain from attacking the first person you talk to. As for DBus, I'm sure the notification library sends a DBus signal that plasma reacts to, but I'm not sure how that would help as long as kalendarac only has code to postpone by 5 minutes and 1 hour.
I also find that the regression is a major one. (I've reported this in https://bugs.kde.org/show_bug.cgi?id=452264 among other significant usability problems.). To add more use cases: ### saving working time shortly before a meeting * I have many meetings where the reminder is 15 minutes, so I can prepare. * When this is checked I delay up to 2 minutes before the appointment, * and then I have the remaining minutes to completely concentrate on something else until the alarm rings when I get up and walk to the meeting room. * This I gain 12-8 minutes of working time. ### using several computers * I have at least three computers with Kontact, that all sync their appontments (using the stone-old Kolab 2 format for historical reasons). * When working from home once a week, I have to click away all appointments that have been there since last starting kontact on this machine. (This is not a delay use case, but... I mention it because:) The old kontact/korgac saved the delay in the internal memory and did not sync it on the machine. A property what would really improve the situation would be to sync the fire time of reminders to the servers and thus also record a potential new delay . So in @Flossy Cat's use case a delay for 3 days or so would be in the backup and also working across synced machines. I am not sure if the current status of the iCalender format - which is often used nowadays - allows it. It might. ## User Interface What about if the desktop notifications bring up a special korganizer/kontact view that holds all fired alarms for appointments, tasks and so on with options that allow at least what the old overview did and a compact overview? (Just an idea.)
Hi Bernhard! Long time no "see" ;-) Yeah after my last comment I had a similar idea, one of the buttons in the notification could trigger a dialog box like the old korgac one, where we can have widgets to define a delay etc. KOrganizer might not be running, so it wouldn't be the right process for popping up that dialog. But kalendarac (the new daemon) could pop up the dialog like korgac did.
(In reply to David Faure from comment #9) > > Actually you should never have removed the original functionality > > "You"? Just because I have a @kde.org address does not mean I was part of > that decision in any shape of form. Sorry, no offense meant – I am not a native speaker/writer of the English language. I used "you" as second person plural. In my native language (German) this is clearly set apart from second person singular and even written different if one is addressing the actual participants of a conversation or a loosely specified group. The text, rendered in German, would have clearly conveyed, I do not mean you as person, but "them" in charge of this solitary decision and "them" responsible for this "decision culture" alienating loyal user and supporters of KDE since the transition from KDE3 … What would be a proper phrase in English to transport this meaning? > On the contrary I was among the first > ones to complain about it when I found out, as a user. And I'm writing here > because I'm on the same side as you, trying to find possible solutions. I concluded this from your phrase "I was told this …" and the provided suggestion and really did not intend to attack you. > I know you're frustrated but please refrain from attacking the first person > you talk to. I would only be frustrated if I would be helpless – that I'm definitely not. I'm annoyed by the nasty surprise of a grave functional regression of core SW I daily rely on. I'm angered to have to postpone my native own tasks and quickly find a workaround or migrate to Thunderbird. I'm alienated by the repeated disregard of the decision makers in the KDE community for the effort loyal and dedicated KDE users put in sophisticated work environments and work flows. > As for DBus, I'm sure the notification library sends a DBus signal that > plasma reacts to, but I'm not sure how that would help as long as kalendarac > only has code to postpone by 5 minutes and 1 hour. Here a sketch of the workaround (which easily could be grown into a professional solution): I presume that some »korganizer« sender will send a message with all necessary information to some »knotifier« endpoint (receiver). As a lot is going on on my session DBus some guidance to narrow the search down would be welcome. I then will hook on this message (via »qdbus-qt5« or »busctl«) and have some script act upon it, probably firing up a suitably tailored »kalarm« command. Then this workaround has to be made permanent – i.e. autostart with each GUI login and deactivate all notifier actions for calendar reminders … The final solution could be achieved along this lines if the »kalarm« developers would honor the kind request to provide an option to do this natively in »kalarm« itself. Some minor improvements suggested within the GUI of »kalarm«'s edit window for reminders and we would have an excellent substitute for (and even improvement over) the old functionality. All at the individual user's choice: Those happy with the current solution just keep it. All the others essentially configure »kalarm« as reminder handler for »korganizer«. »kalarm« should even capable to address Bernhard's problem of stale reminder storms when switching between different machines: It can suppress late reminders … Actually I'm just prototyping a workaround but are stalled by some minor bugs both in »kalarm« and »korganizer« I do not yet fully understand … If you, David, could be so kind to draft persons knowledgeable in »kalarm« or »korganizer« (both skills are needed but not necessarily within one person), this would be very helpful. Thanks in advance.
(In reply to Bernhard E. Reiter from comment #10) > I also find that the regression is a major one. (I've reported this in > https://bugs.kde.org/show_bug.cgi?id=452264 among other significant > usability problems.). Speaking of usability problems (and I share your view on usability problems in KDE PIM and could extend the list …) – slightly off-topic: I now had 2 times the collision warning page when entering a comment, because others commented while I edited my comment. I have no idea, which of the 2 presented options does not pose the risk of unintended nuking the other person's comments. I workaround by copying my comment text and starting anew – any advice from an experienced bugs.kde.org user? > To add more use cases: > ### saving working time shortly before a meeting > * I have many meetings where the reminder is 15 minutes, so I can prepare. > * When this is checked I delay up to 2 minutes before the appointment, … Same here, but with a slightly different workflow: I always have a preparation reminder (typically 15–30 minutes in advance) and a final reminder (2–5 minutes in advance) configured – so I definitely get the final reminder even if absorbed in preparation. I would very much appreciate an "user exit" reminder option (execute commands). Use cases: * Open the necessary tools for preparation, e.g. a specific JIRA issue. * Fire up a web-conference client or a browser with the conference URL as or in parallel with the final reminder. See https://bugs.kde.org/show_bug.cgi?id=481063 and https://bugs.kde.org/show_bug.cgi?id=481068 and https://bugs.kde.org/show_bug.cgi?id=481069 > ### using several computers > * I have at least three computers with Kontact, that all sync their > appontments (using the stone-old Kolab 2 format for historical reasons). > * When working from home once a week, I have to click away all appointments > that have been there since last starting kontact on this machine. > (This is not a delay use case, but... I mention it because:) Well, actually strongly related and my current workaround approach would probably solve your problem, as »kalarm« optionally ignores "late reminders" and would work even without sync'ing … See https://bugs.kde.org/show_bug.cgi?id=481024#c12 > The old kontact/korgac saved the delay in the internal memory and did not > sync it on the machine. > > A property what would really improve the situation would be to sync the fire > time of reminders to the servers > and thus also record a potential new delay . … > I am not sure if the current status of the iCalender format - which is often > used nowadays - allows it. It might. Definitely, if implemented conformant to RFC 5545. > ## User Interface > What about if the desktop notifications bring up a special > korganizer/kontact view that holds all fired alarms for appointments, tasks > and so on with options that allow at least what the old overview did and a > compact overview? (Just an idea.) »kalarm« provides this. Bernhard, I know you once were well-connected into the upper tiers of KDE. If this still holds true, can you kindly draft some knowledgeable persons for »kalarm« and »korganizer« into the discussion? The workaround I'm PoCing might easily and quickly be upgraded to full-grown solution with some knowledgeable help …
Two other potential "workarounds" for you (just for completion): * Stay on the elder version temporarily (to buy more time for a solution) * Go to Kontact from Trinity. It is still maintained > Bernhard, I know you once were well-connected into the upper tiers of KDE. > If this still holds true Unfortunately I do not know (anymore) whom to approach in this case. David of course used to be well connected as well. (*wave*)
(In reply to Bernhard E. Reiter from comment #14) > Two other potential "workarounds" for you (just for completion): > * Stay on the elder version temporarily (to buy more time for a solution) Alas no viable option: * The elder version is not available in the OpenSuSE 15.5 repositories. This would need some tricks and risk instabilities. * It would probably not receive security updates. * The effort would be more than rolling forward to Thunderbird. > * Go to Kontact from Trinity. It is still maintained Again, not very viable: I tried Trinity some years ago when KDE had one of its serious transition fits. While I really like the look and fell of the GUI, the tool functionality stays mostly frozen and the kontact variant would not sufficiently serve me. And again, the effort would be more than rolling forward to Thunderbird.
I'm working on a patch.
(In reply to David Faure from comment #16) > I'm working on a patch. Nice – thank you. Do you care to explain what kind of patch?
Thank you David! I really appreciate it!
A possibly relevant merge request was started @ https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/82
Sorry for derailing the discussions about workarounds with a proper fix ;-) (see description in merge request)
(In reply to David Faure from comment #20) > Sorry for derailing the discussions about workarounds with a proper fix ;-) > (see description in merge request) Thank you – behavior looks good, judging from reading the code. Nevertheless: to derail the workaround discussions the fix needs to be brought back to KDE Gear 22.12.3 – otherwise I'm happy you provided the fix but cannot profit from it with reasonable effort in the near future … Can you be so kind, to apply your fix back to KDE Gear 22.12?
The change contains a new feature and lots of new texts to be translated, I have no idea if it can be accepted into 22.12.3. Let's see if it's approved before discussing backports, in any case. But you don't actually need it to be released in order to use it. You can easily rebuild a patch akonadi-calendar package even right now. You're on OpenSUSE so in your case it means downloading the src rpm (1), adding my change as a patch in the spec file (2), rebuilding the RPM (3), installing (4), done. Or doing that on the opensuse build service to install less development packages locally (but step 2 is the same). (1) sudo zypper source-install akonadi-calendar (2) adding the patch in /usr/src/packages/SOURCES, editing /usr/src/packages/SPECS/akonadi-calendar.spec to add it (3) rpmbuild -bb akonadi-calendar.spec (4) rpm -Uvh *.rpm Please don't ask me to guide you step by step, there are online resources for all this. Debian/ubuntu users can do something similar with apt-get source and debuild.
> You can easily rebuild a patch akonadi-calendar package even right now. It also maybe an option on OpenSuse to use one of the https://en.opensuse.org/SDB:KDE_repositories that is providing newer KDE Application revision to stable Opensuse Leap. Thanks David for any work on the issue!
(In reply to Bernhard E. Reiter from comment #23) > … > It also maybe an option on OpenSuse to use one of the > https://en.opensuse.org/SDB:KDE_repositories > that is providing newer KDE Application revision to stable Opensuse Leap. That I did before reporting the bug – alas then the repositories failed on their internal requirements, perhaps a momentary glitch. But it provides applications only in version 23.08.04, and the patch probably will take some time to shine up, if I not have to wait to 23.08.05 … I will first have to catch up with my work delay caused by this nasty surprise before trying again or following David's suggestion … My workaround via KAlarm from 2024-02-09 (see https://bugs.kde.org/show_bug.cgi?id=481024#c13) works very well and actually brings several benefits and solves the problem of reminder storms you mentioned when switching machines. (Benefits: * (optional) list of recent reminders triggered – very valuable when you lose track on a stressy day * lookeahead of upcoming reminders – very valuable to e.g. shift them proactively if you need some undisturbed time or to preemptively do tasks if a meeting is cancelled * color-coding of reminders * command execution reminders * waking machine from suspend for reminders (not my cup of tea but maybe valuable for some) ) It is really great David restored the eliminated snoozing functionality – thanks – but KAlarm as general reminder handler is worth considering, IMHO. Looking at the further crippling of KDE (see e.g. https://bugs.kde.org/show_bug.cgi?id=481069) after a quarter of a century of choosing KDE I have to consider on which desktop and tool set I will bet for my old age, when I will not be able anymore to workaround, patch, juggle numerous repository and weather dependency messes … (I'm relatively relaxed concerning the desktop having a well-tuned XFCE as fall-back since KDE 4, but the use-breaking regression in KDE PIM hit my hard, unsuspected and with very bad timing …) I consider the change culture in KDE fundamentally broken: Since the KDE3/4 transition I regularly see breaking changes all over the place, "discussed" and "announced" in some very small circles with minimal reach into the end-users. (And IMHO the discussions show these persons do not have a sophisticated usage of the components they are crippling …) The end-users are then hit by nasty surprises a dozen month or more later which then leads to numerous complains, bug reports etc. which are handled quite lukewarm judging from the handling of the duplicate bugs I collected in my bug report. Only when I "threatened" to quickly draft up a working workaround to show the urgency, David took pity and kindly patched and restored the lost functionality. And the patch is – no offense meant, David! – a relatively minor one (still, of course, hours of work I appreciate!). All the while KDE is losing user base – many of the participants of the duplicated bug reports did not partake in this discussion, despite me inviting them in every duplicated report thread. I consider those potentially lost users … Any idea where this fundamental discussion about the change culture of KDE should be started? (bug reports is the wrong place, IMHO)
> Any idea where this fundamental discussion about the change culture of KDE > should be started? (bug reports is the wrong place, IMHO) True, this problem report and the tracker is suboptimal for the topic. For while it would have been one of the mailinglists, but I am not sure about this anymore. KDE e.V. maybe a place to ask about a good channel. However it is most helpful to understand that there are many volunteers that work on KDE's software products. While the whole process may have its downsides and bad outcomes, any volunteer time and effort is appreciated.
(In reply to Bernhard E. Reiter from comment #25) > … > However it is most helpful to understand that there are many volunteers > that work on KDE's software products. While the whole process may have its > downsides and bad outcomes, any volunteer time and effort is appreciated. I know, having contributed to FLOSS continuously (in varying degrees and functions) since 1986 … The volunteer workers on the software products on the other hands should not disrespect the time and effort of the volunteer users in setting up convincing working environments in turn to use in advocating open SW use – be that advocacy intentional or incidental just by example.
Git commit 22fbeb4e48646ab4fa9abce21c4ef1eab31475e5 by David Faure. Committed on 13/02/2024 at 15:57. Pushed by dfaure into branch 'master'. Implement a dialog for the user to choose the suspend duration The "Remind in 1h" action has been replaced with a "Remind later..." action which pops up that dialog. The UI is QWidget-based (reusing some code from korgac). On mobile we could just not show the "Remind later" action or implement a similar QML-based UI. Related: bug 457046, bug 452264, bug 453298, bug 457046 M +2 -0 reminder-daemon/CMakeLists.txt M +5 -4 reminder-daemon/alarmnotification.cpp M +2 -2 reminder-daemon/kalendaracmain.cpp M +21 -5 reminder-daemon/kalendaralarmclient.cpp M +4 -0 reminder-daemon/kalendaralarmclient.h A +136 -0 reminder-daemon/suspenddialog.cpp * A +33 -0 reminder-daemon/suspenddialog.h * The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://invent.kde.org/pim/akonadi-calendar/-/commit/22fbeb4e48646ab4fa9abce21c4ef1eab31475e5
Git commit 0dea82b7100a3f79a81bfdc2e627ba8923131abe by David Faure. Committed on 15/02/2024 at 19:40. Pushed by dfaure into branch 'release/24.02'. Implement a dialog for the user to choose the suspend duration The "Remind in 1h" action has been replaced with a "Remind later..." action which pops up that dialog. The UI is QWidget-based (reusing some code from korgac). On mobile we could just not show the "Remind later" action or implement a similar QML-based UI. Related: bug 457046, bug 452264, bug 453298, bug 457046 M +2 -0 reminder-daemon/CMakeLists.txt M +5 -4 reminder-daemon/alarmnotification.cpp M +2 -2 reminder-daemon/kalendaracmain.cpp M +21 -5 reminder-daemon/kalendaralarmclient.cpp M +4 -0 reminder-daemon/kalendaralarmclient.h A +136 -0 reminder-daemon/suspenddialog.cpp * A +33 -0 reminder-daemon/suspenddialog.h * The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://invent.kde.org/pim/akonadi-calendar/-/commit/0dea82b7100a3f79a81bfdc2e627ba8923131abe