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
The regression is unresolved Kontact Version: 5.24.5 (23.08.5), which is used e.g. in OpenSUSE 15.6 and the corresponding SLE 15 (SUSE Linux Enterprise) as part of the current long term support KDE version, which is these distributions rely on. See (and support) bug 491119 – https://bugs.kde.org/show_bug.cgi?id=491119 PS: Any suggestions for alternatives to Kontact but Thunderbird or Evolution?
It's fixed in 24.02, I'm not sure what else you're asking for. 23.08 is a year old, and time machines haven't been invented yet.
(In reply to David Faure from comment #30) > It's fixed in 24.02, I'm not sure what else you're asking for. 23.08 is a > year old, and time machines haven't been invented yet. Very simple: OpenSUSE Leap 15.6 and SLE 15 SP6 are widespread current distributions used by millions of users. Both rely on the LTS versions of KDE/QT. This results in the following version for Kontact and its components: 5.24.5 (23.08.5) SLE 15 SP6 users have support for several years (5 AFAIR) and are potentially stuck with this fundamentally unusable version … Leap users for at least a year … People like me (and my customers) use versioned distribution like Leap to have a reliable, well tested, stable system. (I personally returned from Tumbleweed to Leap because I was bitten by Tumbleweed several times – for that same reason I don't want to use the OBS KDE factory repositories: just not yet mature and well tested enough for my everyday work, and the dependency resolver has complains …) The quality assurance done by the distributions takes time and effort – with less than a year slack OpenSUSE is relatively quick, IMHO … Either the KDE community is interesting in keeping a user base amongst the Linux distribution users – or not. If yes, port bug fixes back to the LTS versions and thrive. If no, feel free to wither further. I personally are very sick of this kind of discussion, of ill-advised deprecations and functional regressions and the inherent lack of respect thus expressed against the KDE user base – after more than a quarter of a century I will cease to support, recommend and use KDE.
Dear @Flossy Cat, > I personally are very sick of this kind of discussion, of ill-advised deprecations and functional regressions and the inherent lack of respect thus expressed against the KDE user base it is sad to read about your frustrations with some KDE products like Kontact. I can relate because I've experienced regressions a number of times myself. It is good and helpful that you report that those missing or regressing features are very important to you. But also - as I see from your lines cited above - you come to the conclusion that those changes are deliberate and thus a disrespect towards you or users in general. Without knowing how those changes came to be in detail, you cannot know that. I don't know either, but how would you react to a user of your software that approaches you with this conclusion that you meant "ill" by making a change without knowing that you may have been forced to do it by some technical circumstances or budget limitations? Is that reaction helpful? All desktop email clients struggle with getting enough workforce behind them, either by volunteers or professionals. To me that is a wider structural problem. You were asking for alternatives, I know of Claws mail which has is a small but long term team behind it. And Kontact3 from Trinity which has the user defined snoozing still in. Have you tried any of those? Best Regards Bernhard
I understand your frustrations, Flossy Cat. I truly do. KDEPIM has been a big trigger of frustrations for me as well. I am still also facing this bug, cause Devuan Ceres which is based on Debian Unstable also does not yet have a fixed version. Unless in Debian Experimental for Plasma 6 and KDE Gear 6 and KF 6. Soon enough I bet I have it. But I also get that you do not like to run a rolling distro. It is rough these days with the very fast development speed of the Linux kernel and other components. But I do also appreciate that the KDEPIM development team is very small. And they care about their software. That can be seen again and again like for example in the blog posts about the recent meetup they had. Also I see that the change implemented by David has more than 160 new lines and changes more than 30 other lines. That IMHO is quite a bit for a backport. But… another approach would be, to talk with openSUSE people whether a backport can be done and maybe try to bring forth a back port in cooperation between upstream and distro developers? From what I read openSUSE volunteer based team is also quite small and I am not sure whether KDEPIM is a focus for the enterprise variants of SUSE, however that could be an approach where you could use your energy in a constructive manner to resolve the issue at hand for you and others. Especially also if that fix is required by enterprises that use KDEPIM… have you consider to ask for or organize some paid development work on making a back port? Remember a lot of work on KDEPIM is volunteer work. That means it is often enough work done by people who also have to do something else to earn money. If its really the case the KDEPIM is used by a lot of enterprise customers who are affected by this bug, I think it could be possible to raise some money for a paid backport of some sort?
It is a bit contradictory to want to use a "stable LTS version" (which means no new features) and then ask for a new feature to be added to it. I know it's frustrating because that new feature is needed to fix a regression, but it *is* a new feature. I think it's even slightly buggy, it shows the same description twice, in some cases. Not great for a stable LTS version. I am not really part of the KDEPIM development team. I implemented this because I needed it. But it probably needs some polish, and it's definitely too much of a new feature to backport to a stable version (where the main promise is "no new features"). You apply the patch to your RPMs though, that's not very hard with zypper si and rpmbuild.
David, the problem is that the (interation to the next) stable version surprisingly had an important feature removed. Your "new" feature replaces part of the old and missed functionality. So the removal of the old feature in a TLS version is a major defect from the usage perspective. (I understand that you are not a KDEPIM developer so extra thanks for developing a replacement for a part of the removed feature! :) )
Dear Bernhard, thanking you for your soothing words – but … (In reply to Bernhard E. Reiter from comment #32) > Dear @Flossy Cat, > > > I personally are very sick of this kind of discussion, of ill-advised deprecations and functional regressions and the inherent lack of respect thus expressed against the KDE user base > > it is sad to read about your frustrations with some KDE products like > Kontact. This is not about frustrations but about realizing facts and drawing conclusions for the viability of further relying on KDE for my workflows. Let's have a look together at what I perceive as facts here: F1: It is completely normal for code changes to travel around 1–2 years downstream from the development frontier to the end user. F2: So many bugs and detrimental deprecation decisions will only discovered then – that is 1–3 years down the line. F3: KDE changes have – starting with the transition from KDE 3 to 4 – a long history of very nasty surprises for their user base, with fundamental changes and deprecations biting the users without early warning and time for proactive measures. F3.1: "Announcements" are typically in the style of the beginning of "Hitchhiker's Guide to the Galaxy": in some obscure, small mailing lists or the commits some deprecation notice is given. (I'd had to follow around 400 such sources to cover my SW base against nasty surprises – CONCLUSION: not viable …) F3.2: At least the deprecation and regression this bug is about as well as the Bug 481069 both seemingly were decided by people either not having a sufficient sophisticated use of the SW components they decide to deprecate or they didn't care for the effect on the user community. Evidence: Even very unsophisticated users of calendaring see the necessity for flexible snoozing of reminders! (Or the whole decision process is haphazard, not providing for any consideration of stake holders, impact analysis, etc., and allowing for random whims of individuals.) CONCLUSION: I can not rely on KDE SW for long-term use anymore. F3.3: Supporting F3.2, the explanations given so far for these decisions do not hold water: If you dive into the developer discussions around the deprecation leading to the regression in Bug 481069, the primary argument is essentially "can not be implemented on smartphones" … The regression was defended with "we don't see any bug reports for this component, so it is not used" – equivalent to saying: we deprecate all functionality mature enough to not cause frequent bug reports anymore … (Next absurd defense line: "we cannot learn real usage because of privacy" – this in a discussion on "bugs.kde.org", which proliferates the mail-addresses of the bug reporters like there is no tomorrow (I've burned several pseudonyms here meanwhile – my suggestion to change this problematic behavior of "bugs.kde.org" was not greeted with politeness …)) Similarly here with this bug: "we want to switch to a notification framework available on smartphones" (and drop functionality without consideration of the impact) CONCLUSION: User experience and satisfaction ("no nasty surprises", functional and UI continuity, etc.) is not taken in consideration and/or desktop experience is no important consideration anymore -> I can not rely on KDE SW for long-term use anymore. F4: KDE is either not capable or willing to consider F1 and F2 and to correct regressions in LTS versions at least 3 years backwards. When David kindly fixed the regression in February the version 23.08 was just half a year old and it was already known it will be part of LEAP 16.6 and SLE 16.6. This means users are stuck with this regressions for a long time – in case of LEAP 16.6 at least till summer 2025. CONCLUSION: That is not viable. I could use a workaround for the last 6 month because of a hiatus, but not any longer. (And using OBS KDE to get a more current version fails on numerous resolver complains, taking a lot of effort to resolve and seemingly resulting in the choice to drop other SW – the effort extends to several systems, not acceptable … The same is true of compiling from source, as I would lose automatic security updates …) F5: In both bug reports I offered my help and support for implementation as a seasoned computer engineer if I'm pointed to introductory material or are guided. No reaction to this offer … CONCLUSION: Active support is either not wanted or needed. OVERALL CONCLUSIONS: 1. KDE does not care for its user base and does not respect the time, effort and love sophisticated users invested in sophisticated KDE working environment, which shine and promote KDE. 2. This leads to a vicious circle and downward spiral of the user base and their support (take me as an example) FINAL CONCLUSION: With Kontact as last application strongly profiting from running under KDE natively gone, I will migrate to my fallback GUI environment XFCE (honed and kept since the KDE3->4 desaster) and drop Kontact as my PIM. > I can relate because I've experienced regressions a number of times > myself. It is good and helpful that you report that those missing or > regressing features are very important to you. That is part of my active support of FOSS since the eighties … > But also - as I see from your lines cited above - you come to the conclusion > that those changes are deliberate and thus a disrespect towards you or users > in general. Without knowing how those changes came to be in detail, you > cannot know that. I did the detailed research – see above. > I don't know either, but how would you react to a user of > your software that approaches you with this conclusion that you meant "ill" > by making a change without knowing that you may have been forced to do it by > some technical circumstances or budget limitations? Is that reaction helpful? See above. It demonstrates fundamentally flawed approaches and processes. If you, Bernhard (other kind souls in this bug thread are cordially welcome too), will support the discussion in discuss.kde.org, I will give it a last try. (But not delay my migration.) > All desktop email clients struggle with getting enough workforce behind > them, either by volunteers or professionals. I know – for that reason I offered active programming support. But see F5 … > … You were asking for alternatives, I know of Claws mail which has is a small but long term team behind it. Thanks. I'll give it a look. > And Kontact3 from Trinity which has the user defined snoozing still in. I tried. While I still think KDE3 was the best desktop so far and Trinity is doing a good job to keep it, it also stagnates and, IMHO, is doomed to wither. Kontact3 alas lacks a few features of Kontact5 I actually use … Best regards, Flossy Cat
Hi Flossy Cat, thanks for taking the time and writing a long response, which I mostly have to think about. Except: > F5: In both bug reports I offered my help and support for implementation > as a seasoned computer engineer if I'm pointed to introductory material > or are guided. > No reaction to this offer … > CONCLUSION: Active support is either not wanted or needed. KDE welcomes people, needs and wants active support! The problem often is that if someone offers this on a specific defect is that (because of Moore's law) you often put more effort into the mentoring or guidance than to fix it yourself. Especially if the defect is a chain of technical decision and dependencies. Thus mentoring someone makes sense if there is high chance that this person wills stay within KDE at least for a while. Another aspect is that getting a development setup and putting contributions forward is already documented in general for KDE products. So anyone could (in principle) do it without guidance. You could just set this up, come up with patches for a code variant into mobile and desktop and contribute them without much specific interaction. (Yes I am fully aware that this is a suboptimal decision process when looking at it from a greater scale.) You could also propose a backport patch to OpenSuse LTS. To be more specfic: What kind of help would you need to come up with improvements on aspects? Getting to back on some other aspects, though it somehow gets beyond this issue. Best Regards, Bernhard
(In reply to David Faure from comment #34) > It is a bit contradictory to want to use a "stable LTS version" (which means > no new features) and then ask for a new feature to be added to it. I know > it's frustrating because that new feature is needed to fix a regression, but > it *is* a new feature. Your claims are counterfactual: This bug report is about a regression and re-establishing functionality which was present in previous versions since many years and were deprecated without announcement and any consideration on the usability of Kontact for calendaring afterwards. "Regression" is part of the title and pervades both the bug report itself as well as the discussion thread. The patch you kindly provided – according your own words – reused code from "korgac" (which was scraped without consideration of the impact, which is the root cause of the regression), proving the regression. As stated in comment 8, this change happened 2 years before my bug report and similar bug reports like mine existed 6 months after this crippling change – i.e. 18 months before my bug report. This should have been early enough to avoid having a crippled Kontact (unusable for calendaring) make its way into LTS and distributions like OpenSUSE and SLE. The ignored users of these early bug reports probably have left the KDE user base meanwhile. I'd worked around 6 month till the advent of LEAP 16.6. I'd would have to wait roughly a further year to see your patch in the regular distribution. (Or to compile myself and lose automatic security patches or wade through the dependency hell of OBS KDE Factory versions and lose other SW because of resolver clashes – on several systems.) That is neither viable nor acceptable, and in any case much more effort than to migrate to a new PIM solution.
(In reply to Martin Steigerwald from comment #33) > I understand your frustrations, Flossy Cat. I truly do. KDEPIM has been a > big trigger of frustrations for me as well. Thanks for your quantum of solace, but this is not about "frustrations" – please see comment 36, my answer to Bernhard. > … > But I do also appreciate that the KDEPIM development team is very small. And > they care about their software. That can be seen again and again like for > example in the blog posts about the recent meetup they had. When I opened this bug the crippling change (silent scraping of korgac) was already 2 years old. (see comment 8 and the related bugs) Very obviously nobody considered the usability impact of this: Even the most simplistic users of any calendaring tool I can question, immediately answer that only being able to snooze reminders for 5 min or 1 h would not be acceptable … The first bug reports complaining about the effects of this change happened 6 month after the change and 18 month before my bug report. To no avail … – they were ignored … I can't rely upon software with this level of care – and I don't care for software which is cared for like this. > Also I see that the change implemented by David has more than 160 new lines > and changes more than 30 other lines. That IMHO is quite a bit for a > backport. David extracted code from the scrapped "korgac" and re-implanted it. This is neither a "new feature" nor "160 new lines" if "new" is used with its usual meaning of "something not present earlier". The change to fix the regression might change around 200 lines to arrive from "crippled" to "usable" again, but many of these (as well as the functionality) have been present for many many years. > But… another approach would be, to talk with openSUSE people > whether a backport can be done and maybe try to bring forth a back port in > cooperation between upstream and distro developers? From what I read > openSUSE volunteer based team is also quite small Exactly. The small KDEPIM team causes a use-breaking regression by some ill-considered decision. It then ignores all early warnings about the problem and freezes the LTS versions so that when these decisions start to hurt users relying on KDEPIM no easy backport of the fix and no easy propagation to the suffering users is feasible. Instead I should involve the (equally) understaffed openSUSE team (and other users their respective distro teams). This multiplies the effort needed in comparison with the KDEPIM team just realizing how ill-considered their decision was and fixing it. If FOSS teams are understaffed (and they definitely are!) this is a very stupid strategy. Or we go with David's idea of each user compiling for themselves, further multiplying the effort (and dangerous, as the self-compiled version does not receive automatic security patches). I go with my idea: switch to a PIM solution actually caring for end user experience … > and I am not sure whether KDEPIM is a focus for the enterprise variants of SUSE, It isn't. The default choice there is Evolution. I always wondered why, because I regularly every few years reevaluate my SW choices, and Kontact so far always had a slight edge on Evolution and Thunderbird (but the gap was closing). With this regression Kontact is far behind and the whole handling of this regression deeply undermines my trust in KDEPIM. If the SLE team had similar experience I now understand the preference for Evolution. > an approach where you could use your energy in a constructive manner to > resolve the issue at hand for you and others. Especially also if that fix is > required by enterprises that use KDEPIM… It would be … > have you consider to ask for or > organize some paid development work on making a back port? Remember a lot of > work on KDEPIM is volunteer work. That means it is often enough work done by > people who also have to do something else to earn money. I'm a seasoned computer engineer supporting FOSS since 1986, mostly by contributed code and bug fixes and I offered my active support with this bug report – to no avail.
Dear Bernhard, (In reply to Bernhard E. Reiter from comment #32) > … You were asking for alternatives, I know of Claws mail > which has is a small but long term team behind it. … Thanx for the hint. But Claws is an e-mail client and calendaring is only available as a plugin providing for a single calendar. I have the need for multiple calendars, making – so far – Evolution and Thunderbird the only viable solutions to Kontact …
Dear FlossyCat, > Thanx for the hint. But Claws is an e-mail client and calendaring is only > available as a plugin providing for a single calendar. > I have the need for multiple calendars, making – so far – Evolution and > Thunderbird the only viable solutions to Kontact … Thanks for trying and giving feedback! (I haven't tried the calender plugins of Claws for while so I cannot say what there feature are.)
Hi Bernhard, (In reply to Bernhard E. Reiter from comment #37) > … > > F5: In both bug reports I offered my help and support for implementation > > as a seasoned computer engineer if I'm pointed to introductory material > > or are guided. > > > No reaction to this offer … > > CONCLUSION: Active support is either not wanted or needed. > > KDE welcomes people, needs and wants active support! Then, I wonder why nobody pointed me to some kind of primer, guidance, an onboarding process or anything like this – because I explicitely asked … If KDE needs and wants active support this kind of things should be available, know to the bug triage theme and promoted on request. > The problem often is that if someone offers this on a specific defect is > that > (because of Moore's law) you often put more effort into the mentoring > or guidance than to fix it yourself. Especially if the defect is > a chain of technical decision and dependencies. Thus mentoring someone > makes sense if there is high chance that this person wills stay within KDE > at least for a while. I'd provided in several bugs the code segments, commits or discussions, where the root cause lies. I provided code snippets. Some capability can be plausibly assumed. This should be sufficient to at least explicitly ASK if I will provide lasting support (instead of silently assuming I wont – which BTW is a wrong assumption …) > Another aspect is that getting a development setup and putting contributions > forward is already documented in general for KDE products. So anyone could > (in principle) do it without guidance. You could just set this up, come up > with patches for a code variant into mobile and desktop and contribute them > without much specific interaction. (Yes I am fully aware that this is a > suboptimal decision process when looking at it from a greater scale.) I explicitly stated with my support offers that I want guidance because I'm aware of the complexity of the KDE products and want to avoid acting against plans or carelessly introduce detrimental side-effects. > You could also propose a backport patch to OpenSuse LTS. As explained in my answer to Martin: This multiplies the effort and wastes the scarce resources of several downstream distribution teams (if other users replicate the request to their distribution support teams) More important: F6: The first bug reports arrived 6 month after the regression was coded – more than 2 years ago! There is no "official reaction" of the KDEPIM team on any of these. Further there is no KDEPIM team reaction on similarly fatal bug 483545. Meanwhile I know for sure: this is no matter of potentially old, incorrect mail formats: It happens in my productive system to! (If you use Kontact, you should dig into it) AFAIR Kontact (more exactly the whole Kolab suite) was once officially funded, supported and used for public authorities (as a substitute for Outlook). For that reason I actually expected a backport by SLE. This not happening I conclude the use by public authorities has ceased … 2 years of silence by the KDEPIM team and no reaction to the fatal bug 483545 let's me conclude: there is no proper maintenance of Kontact anymore … Bug 481069 tells a similar story on KDE level itself: ill advised functional regressions biting a lot of users. Bug 491130 is about a fatal regression on KDE level, breaking very old, very fundamental desktop functionality – with no "official" maintainer reactions so far. KDE maintenance level perhaps is also already questionable?!? > To be more specfic: What kind of help would you need to come up with > improvements on aspects? > > Getting to back on some other aspects, though it somehow gets beyond this > issue. I think the proper place for this discussion would be discuss.kde.org and this discussion would need some supporters because it will require IMHO fundamental changes in the way KDE is curated, if the decline is to be stopped …
Seriously, Flossy Cat, I have given up on reading your very lengthy comments completely. You offered help in a bug report? Do you really consider it fair to expect the very small KDEPIM team to monitor all comments in all of their bug reports for an offer for help? With all the hours you have used to write very lengthy comments in this bug report, you could have: 1) Researched yourself where a suitable place for offering help would be. It could be kde-pim mailing list. It could be their Matrix channel. It could be both. I do not think discuss.kde.org would be suitable, cause AFAIK it is meant for user discussion. 2) Researched yourself for resources on how to start contributing to KDE. Sure, I bet the documentation on that is still not perfect while AFAIK some people worked on it recently, but there is documentation available. 3) Probably even back ported the patch from David and posted a merge request on invent.kde.org. I am going to unsubscribe now from this bug although I would have loved to stay up to date. A bug tracker is no discussion forum. Especially not on a bug report that is marked as RESOLVED / FIXED¹. The discussion here does not add anything to solving the issue you have. It could go on and on for eternity without any tangible result. This is why I aim to have this as my last comment here. Write a mail to kde-pim mailing list for example. Ask on their Matrix channel. And allow them some time to respond. No one said the within the KDE project everything is working out perfectly, but in case you like to change the whole project around *before* doing some steps to actually contribute… good luck. I do not believe that is going to work out. KDE in my point of view is a do-ocrazy to some extent. It goes the other way around: First you contribute, build up some respect within the community and then you have a say on how things are done. [1] I think a request for back porting the patch that reintroduces the functionality should be a different bug report referring to this one.
(In reply to Martin Steigerwald from comment #43) > … > 1) Researched yourself where a suitable place for offering help would be. It > could be kde-pim mailing list. It could be their Matrix channel. It could be > both. I do not think discuss.kde.org would be suitable, cause AFAIK it is > meant for user discussion. > > 2) Researched yourself for resources on how to start contributing to KDE. > Sure, I bet the documentation on that is still not perfect while AFAIK some > people worked on it recently, but there is documentation available. So I did with my Kalarm bug reports. The maintainer kindly pointed out, that both documentation and git repository were outdated and the current git is residing somewhere else … Wasted time for both of us. Nevertheless issues were resolved promptly and friendly. Farewell.
The bug is not resolved or fixed for the version it was reported!
There is no guarantee that a bug will be resolved for the version it is reported. Actually it even even highly unlikely. Usually it would likely be at least a minor bump of the version number to tell the "buggy" and fixed versions apart. However the issue is indeed solved in KDEPIM 24.08. I am offered to set a custom period for the reminder. So I set this issue to resolved and fixed again. Please keep it that way. Thank you a lot for fixing it, David, although it was needed, as far as I understood it, to implement a new feature around the standard notification features in order to do the fix! Thank you! It was explained here why a back port of the fix is not feasible. See for example my comment #33 and also what David Faure wrote. I appreciate it can be frustrating to wait till your distribution carries the necessary KDEPIM version, especially when you are on a stable distribution with a long release cycle.