Interested in eternal fame and fortune within the KDE community? Want to be forever known as the person who implemented the Number 1 most requested feature in KDE? Read on and find out how!
In Luca's recent blog post he listed the top 10 KDE Brainstorm Ideas, and there at number 1 is supporting the creation of PIM events via the Plasma Clock/Calendar. This wish has also long battled it out for the Number 1 spot in bugs.kde.org voting as well. And it's something I promised to do at the last Akademy nearly two years ago. Whoops :-(
Implementing 2-way PIM support requires two separate pieces of work. The obvious part is making changes to the Clock/Calendar Applets to create Events, but before that can happen we need to create the back-end Plasma Service that will talk to Akonadi to do the actual work. It's writing this back-end code that I've stalled on due to too many other commitments, and it's where you can find eternal fame by picking it up.
I've documented almost everything I know about the current state-of-play of the Plasma Clock on the Community wiki, so anyone interested can pick-up where I've left off. The page points to various resources and provides a basic outline of what needs to be done to create the Plasma Service. I've also put down a few ideas about improvements to the Applets which people are free to ignore.
A key point here, and a lesson hard learned when we wrote the read-only PIM DataEngine is that PIM is a complex subject area and Akonadi is our abstraction layer designed to make PIM easier. Trying to fully re-implement all the Akonadi API and specialist GUI widgets in Plasma is not a very smart idea. Plasma only needs to offer a basic level of services that general use Plasmoids like the Clock need to offer, such as adding a single-occurrence Event or a Todo item. Any advanced features like recurring Events and meeting invitations should be left to the PIM applications via an option in the Plasmoid to launch the full application. If someone wants to write a Plasmoid to support complex PIM editing then they should directly use the Akonadi API in C++, or generate proper language bindings for Akonadi / kdepimlibs in their language of choice.
Another feature we need added in Plasma is the ability to choose what Events to display. At the moment we are just pulling in the Default Calendar (or is it all Calendars?). What would be great is if you could choose which Akonadi Collections to display, i.e. only show Personal Events in your Personal Activity, only show Work Events in your Work Activity. Again, this requires changes in both the DataEngine and the Applets.
One other area that needs solving is what to do when a user doesn't actually use KDEPIM or Akonadi for their PIM needs but Akonadi has still been installed by the distro by default? At the moment we launch Akonadi by default inside the Plasma Calendar as soon as the user clicks on the Clock, and query it for any available events. Naturally it finds none, but by then it is too late, Akonadi has been launched and is seen to be using resources. "Oh noes, big bad bloated KDE!" Many distro's avoid this by changing the default setting to not showing Events, but then users may not realise that they can be enabled. A far better solution would be if there was a passive way to query if any Akonadi Calendar Resources have been configured and only launch Akonadi if they have. We could also then offer a wizard to configure Akonadi Resources if none have been. This of course is something that would have to be implemented by the KDEPIM/Akonadi team.
I had originally planned to post this before Akademy and say "come speak to me at Akademy if you're interested" but sadly problems at work led to my leave being cancelled and my having to miss Akademy for the first time in 5 years :-( So instead if you're interested in working on any part of this, please drop a line to the Plasma or KDEPIM mailing lists as appropriate and I'll get back to you.