Akonadi Meeting, Day 1: Discussions & API Review
I was one of the last to arrive at the Akonadi Meeting. When we were all settled, we discussed the schedule for this weekend. I objected to the API review starting on Saturday 8am, but otherwise the schedule is packed and fun.
After that, we did an overview of the pim current situation:
- KOrganizer: Porting is going on, but we will not manage to release an Akonadi based version for KDE 4.4, so that will show up not earlier than 4.5
- KJots: A relatively new addition to the pim module is KJots. It is fully Akonadified and will be released with 4.4 as usual.
- Work on the SyncML client is improving steadily. It will be merged into KDE 4.4. It is an Akonadi Agent and I think we still need an GUI for it, but the framework will be there. I’ll blog about it more when we have had the demo.
- We have little trust OpenSync will ever deliver what we need. That means all the code we have using that, will move to playground. That includes the KitchenSync application.
- KAddressBook is Akonadified and will be released with KDE 4.4. We still need to port some PIM application to use the new KAddressBook API instead of the old one, but that’s work in progress.
- KMail: Porting is steadily continuing and progressing nicely. Though it won’t be ready for KDE 4.4.
- KNotes, it is largely unmaintained I think. The functionality is probably taken over by KJots and the notes plasmoid. So we will remove it from kdepim.
- Wizards. Volker has a prototype for configuring your mail client, based on kross script / get hot new stuff. Basically the idea is that you can select that you have a GMail account for example. All the right settings are then provided and the user only has to enter the username and the password. GHNS can provide new or updated scripts and this makes it possible for companies to deploy there own scripts to their users.
We also discussed the possibility to get rid of KUniqueApplication for kdepim applications. With the move to Akonadi the technical problems of the back-end is gone, so we can actually can rid it of it. It has some consequences for the communication in relation to standalone vs. apps in Kontact, so that requires further investigation.
Also we decided that we want to get rid of all DBus calls which control other application. Instead of launching KAddressBook and order it over DBus to show a contact. Apps should simply show a dialog which holds the contact data, much more friendly for the users. Every application that is getting ported to Akonadi should keep that in mind; provide widgets that can be reused by other application.
After we went out for dinner, we started on the API review. Due to a lot of KDAB activity in combination with the work of some SOC students, we have an enormous amount of API to review. We started with the stuff from Akonadi core and finished way after midnight.
>KNotes, it is largely unmaintained I think. The functionality is probably taken over by KJots and the notes plasmoid. So we will remove it from kdepim.
Please, don’t kill knotes. As much as I thin that the combination Kjots+plasmoid could do the job, it doesn’t give you the killer feature of having a note on top of your screen, effectively taking space. This is what makes post-its so valuable. And what about the work done on libstikynotes?
@Luis: the fact that you want to use a top-level window for notes doesn’t mean that you need a full application only to do that. You can run plasmoids in separate windows as well.
I think that is one of the biggest problems of KDE 4 – it just takes a very long (too long?) time, to get it completed finally. There might be great technologies, libraries, datastores, and what not. But what are these things worth, if they are not used by applications?
Even in the fifth release of KDE 4, KDE 4.4 (if you count 4.0 as starting point), a big and prominent app like KMAIL does not make use of the goodies KDE as desktop provides – in this example Akonadi. Oh boy….
The same goes for Strigi / Nepomuk, it is still far away from being ready for day to day use, or at least it seems so (tried to enable it in Kubuntu 9.10 without success – can’t remember the error message at the moment, maybe I’m getting old…).
K3b port is still not finished, a few days ago I a new version of KMyMoney was released – a QT3/KDE3 version?!
I don’t want to blame anyone, but KDE4 (including the apps, because a desktop without apps is almost worthless) is really a looong way. And I think this is a problem regarding the reputation of KDE these days.
To bad I’m not a coder at all (tried to learn coding a few years ago, but couldn’t get used to it). Try to help in doing translations every now and then (sometimes I’m short on time too) in Kubuntu, but I’m afraid the translations might never see the light of days because of Rosetta (why do they have to do there own thing, when projects allready translate things…).
Regards, Ralf
I think you misunderstand the releases. We have never ever said that we are finished. We are constantly improving the code and making new features and solving bugs. KDE3 versions work fine in KDE4, so sometimes the port takes a bit longer, if you want it to move faster, we need more developers.
Especially monster applications like k3b, konversation, kmail have certain complexity that it can be hard to port fast. Also sometimes you want to go slow to not break stuff. Like lossing contacts or mails, that would be unacceptable.
Tom,
do you think you can expand on OpenSync — in particular what is wrong with it, and whether there are alternatives. The state of syncing under Linux is rather deplorable as it is, and if OpenSync seems not a solution, then we’ve got a big problem.
I fear that full answer might require a separate post, though ;-)
The main problem with opensync is the stability of their API. They keep making API incompatible changes which break existing applications like KitchenSync time after time. Other than that, the promised release from OpenSync is now 14 months late. This can not been seen as an incidental problem, this is going on for years. SyncML seems like a project which fits our needs better.
As said I will talk more about this later on, when we have had a presentation of SyncML.
> KJots: A relatively new addition to the pim module is KJots. It is fully Akonadified and will be released with 4.4 as usual
Have you thought about an application like Basket (basket.kde.org) for notes? It’s a really good (KDE3) app, that has no KDE4 counterpart. It’ll be cool to see it ported to KDE4.
Ok, I’ll wait for more posts. The primary concern I have about SyncML is that I don’t think Windows Mobile supports that at all.
I must say that I am a bit disappointed about akonadi stuff as well. It seemed to be very promising but it is a mess. Configuring kmail, korganizer and kaddressbok is totally confusing. I have no idea how many times I had to remove everything and start over. There are files for address book and calendar, then the akonadi connectors and I have no idea what is saved where in my system. In kaddressbook and korganizer i see the akonadi stuff again but I am not allowed to edit and selecting entries in the tree doesn’t change much.
Simple synchronization with online calendars or a phone is not working at all. Phone synchronization is maybe worse than 5 years ago cause back then I was able to do it at least on the command line.
I think it would really help to simplify settings and display of resources. Cause I think many people just don’t know how to use it.
I really would like to help but unfortunately I am not very good with C++.
I must object, Akonadi is far from a mess. Quite the opposite. From the messy implementation we are moving to a robust, powerful framework.
The migration of the old stuff to akonadi happens in the beta releases and trunk. So if you are running those, you can get what you describe. If you only run official released versions, the data should not be migrated and you should not end up with that mess.
The synchronisation problems are not caused by us. They are caused by having no framework available to sync properly. We have tried opensync by making kitchensync and that failed due to continues API breakage from them. Not our fault. And especially not Akonadi’s fault. Akonadi is key to the solution here, not the cause of troubles.
Being a stupid user here: SymcML would be the client used for (two way) synchronisation with the most common phones, right?
With or without a GUI, I would thus be able to sync my Symbian / Maemo device with my Kontact agenda.
This is much anticipated!
” Ok, I’ll wait for more posts. The primary concern I have about SyncML is that I don’t think Windows Mobile supports that at all. ”
Fortunately, Microsoft now is in a position where it would have to comply with standards. Windows Mobile needs all the help it can get.
@VladimirPrus:
As toma already pointed out, OpenSync has it’s problems. I did the GSoC about SyncML and I started of with their actual SyncML implementation called ‘libsyncml’, which is the foundation for OpenSync’s SML plugin. The same criticism can be applied here, lot’s of BIC changes an ugly API that is not stable and tends to crash often. So, from my POV this won’t have a bright future. Instead we’re aiming for a solution that is more tightly weaved into KDE PIM stuff. Currently this is done by using another SyncML implementation directly in an Akoandi agent. As a bonus, you can fetch client software for nearly every platform (including Windows Mobile) from Funambol: https://www.forge.funambol.org/download/#
Just a note regarding the wizards: How about you spare me selecting anything (as in the provider) but just let me enter my email address and password and then derive the provider from the email address. Combine that with a method to select the most secure settings automagically via the “Test server capabilities” thingy and it should be the easiest and most userriendly way ever seen.
Then provide an easy way to get new providers via GHNS so it can be updated outside of KDE releases and also provide a list of known ones with every KDE release so it doesn’t depend on GHNS but GHNS can be used to correct the list between releases.
IMHO the best thing since sliced bread ;D
I think you got the idea prefectly ;-) I suck at explaining…
When I wrote “mess” I mean the interface for a normal user. Maybe mess is a hard word but what I mean is that there are so many connectors that a user does not know what to do and cannot understand the difference between them. And I am pretty sure that normal users don’t even care.
For example are all calendar sources synchronized with each other no matter what it is?
Maybe it would be a good idea to put better understandable information in the box where a user selects them. For example “traditional calendar source” and “vcard file” isn’t that the same?
SyncML is all well and good, and many new phones support it I’ve no doubt, but unless I’m mistaken any solution based solely upon it will limit you to only those devices that do support the SyncML protocol.
I know OpenSync hasn’t delivered on its promises, but I think the promise is still there and I hope we can manage to get a stable release out soon. FYI the API is semi-frozen now so there should be no major changes until after the stable release.
I think that’s what Tom was getting at: introducing “high-level” user interfaces to replace/supplement the current “low-level” ones.