[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #15 from Flossy Cat --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #14 from Bernhard E. Reiter --- 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*) -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #13 from Flossy Cat --- (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 … -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #12 from Flossy Cat --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #11 from David Faure --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #10 from Bernhard E. Reiter --- 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.) -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 Bernhard E. Reiter changed: What|Removed |Added CC||bernh...@intevation.de -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #9 from David Faure --- > 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. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #8 from Flossy Cat --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #7 from Flossy Cat --- Comment on attachment 165676 --> https://bugs.kde.org/attachment.cgi?id=165676 Screenshot of a notifier popup This screenshots serves as comparison to the information actually provided via the "execute command" hook – see comment #5 -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #6 from Flossy Cat --- Created attachment 165676 --> https://bugs.kde.org/attachment.cgi?id=165676=edit 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 -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #5 from Flossy Cat --- 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«") … -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 David Faure changed: What|Removed |Added CC||fa...@kde.org --- Comment #4 from David Faure --- 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...). -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #3 from Flossy Cat --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #2 from Flossy Cat --- 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) -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #1 from Flossy Cat --- SEARCH FOR A WORKAROUND Within this comment thread I suggest to collect the discussion about workarounds. -- You are receiving this mail because: You are the assignee for the bug.
