After battling with various bugs I would like to take the opportunity to list here some issues I encountered with setting up and using calendars in KDE Plasma as it feels like the usability of this rather basic function in a DE (not necessary in terms of of code but in terms of UX/user expectations) is - putting it mildly - rather suboptimal currently…
Recently I have had issues setting-up the Nextcloud Calendars in KOrganiser. After following all the setting up steps and everything going well, the resource remains “offline”, the name of the resource does not update (it says “CAlDAV groupware something” instead of “Nextcloud”), and overall it just doesn’t work. Following exactly the same steps in Merkuro settings (and literally every steps / UI look identical), it just works.
While KORganiser is a good and powerful software, it really looks outdated on a modern desktop. Merkuro is better visually but is still quite buggy and the development does not seem very active (btw I have reported those bugs in Merkuro Git page just in case you wonder).
I thought it could be useful to have it all in one place for a KDE PIM dev. While not resolving it all (like I’m not expecting a full remake of KOrganiser - which is beast of a software and great - to happen anytime soon), at least having a simple, visually clean and robust way to perform the basic calendar functions of viewing, creating and modifying events would be wonderful to have easily accessible in Plasma. So maybe addressing 1) and 2) and adding a clean UI so those basic functions can be performed from the Digital Clock widgets? Just an idea from someone who at the end of the day knows very little, and so I’m certainly not intending to tell actual KDE Devs what to do or how to do things, I’m just trying to suggest stuff and do my bits to improve KDE Plasma .
The code to perform functions such as add, modify and delete events is already there and in most cases work so what could be nice would be a small UI in the beautiful style of the Clock widget and accessible from that widget to perform those actions in a consistent and robust way (even with limited options to start with).
Say when hovering over an event in the clock widget we could see a modify and delete button appear as in the mockup below (sorry for terrible graphic skills, of course in real life the button would not be white background etc.), and when clicking on either Add, Modify or Delete we get a small UI that appears (again in the visual style of the widget) to perform the task.
Thanks for the reply and I hope you are right regarding Merkuro. What worries me is that the development seems to have been a little inconsistent since its inception (Kalendar as it was). It is in an OK state now though. I just hope things regarding providing basic calendar functions will still improve and hopefully integrate better with Plasma Applets.
Taking of which, I’ve just noticed something odd. You see in the screenshot/mockup I provided there is a [+ Add…] button. This was not a visual addition from me but something that was really in my system, and when I clicked on it it would open KOrganiser. But now it has disappear. You don’t know how to bring it back by any chance?
Zooming out a little bit, I guess this post is somewhat linked to the rather heated, polarised and misleading debate of, should Devs be fixing bugs to have things functional or build new things. I am NOT going to enter it in details and overall I simply agree with @ngraham’s very good post here which summarises the issue very well Why don't you just do bug fixes for 1 - 2 years? - #8 by ngraham. However, I wondered if one compromising approach could be for the KDE project to conceptually select a specific set of “basic” desktop functions that should be provided as part of the DE, which for example (and in relation to this post) would contain the ability to set-up and use calendars, with at first provide a limited set of features so it is more easy to check for bugs and ensure these are working well, and do more extensive testing/bug fixing on those as part of new releases / bug fix releases. Then slowly add and test additional features on those core DE provided functions. But then this leaves the freedom outside of (and parallel to) those basic/functions provided as part of the DE for devs to work on what they what / are paid for and for the DE provide a whole other world of additional/more feature rich/diverse, but less well tested, stuff.
In the example of this for the Calendar function this could look like:
as basic features the DE ensures that there is a reliable way for people to set-up calendars, add/remove/edit events (I mentioned the UI for that could be the Clock Applet but it doesn’t have to). There is more testing and focus on bug fixing on these to ensure reliability.
but then on the side we can still have applications with more bells and whistles like KOrgniasers, Merkuro, the handling of tasks and contacts as well as calendar events, etc.
Had a quick look at the code and it seems it is checking if either KOrganizer or Kalendar are installed by checking for their respective .desktop files (org.kde.korganizer.desktop and org.kde.kalendar.desktop)
@carl Assuming the latter used to be what is now Merkuro Calendar then this check should probably be (additionally?) for org.kde.merkuro.calendar
The check is also just considering the “first” registered application for calendar data (app the user prefers for calendar data).
Might not hurt to check all offers if it wants to have one of two specific ones.
Since Merkuro Calendar has done the heavy lifting of creating QML API for accessing the calendar system, this might be as simple as import org.kde.merkuro.calendar inside the digital clock applet and using the CalendarManager object from that module.
I.e. it could likely be done by anyone with Plasma/QML skills without having to dig into C++ PIM APIs.
.