Help Test the Next Generation of KDE's Kontact

The KDE PIM team has made available a beta version of the next-generation groupware client suite Kontact. The new Kontact is built on the Akonadi framework, sharing infrastructure for syncing with online services across applications. While the first bits of Akonadi integration already made their entry in KAddressBook as delivered with 4.4, this beta includes Akonadi versions of most of the other Kontact components, including email using the new KMail2.

As the Akonadi-based Kontact marks a major step in the evolution of KDE's groupware apps, the KDE PIM developers decided to apply a feature-based release schedule to this port. It will be released when it's ready, which is realistically still this year. In order to achieve this, we rely heavily on community feedback, so please give this beta a run and get back to us with your feedback, preferably in the form of bug reports on bugs.kde.org.

KDE PIM Beta3 is not suitable for production use. For those who rely on stable groupware applications, the right choice is the KDE PIM we have delivered with KDE Applications 4.4 (latest version is 4.4.5). This version remains fully supported and the recommended choice for everyone but testers and those interested in the next-gen Kontact.

For more detailed information about this beta version, for Akonadi in general and for migration scenarios to and from Kontact-based Akonadi, please refer to this blogentry, or the Akonadi Project page.

Dot Categories: 

Comments

Can somebody point to correct SVN branch where I can get source code to build from?

Hmm... it should be this:

svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim

No, that's trunk.

4.5beta3 source is at tags/kdepim/4.4.93/kdepim

4.5 in progress is at branches/KDE/4.5/kdepim

I am willing to test it, but don't want to build it. Are there kubuntu or opensuse packages available somewhere?

I just added the repos from that link and am getting an error saying that there are dependencies on kdebase-runtime >= 4.5.2 I can't find any repo with that version anywhere, I have 4.5.1 in kde-factory repos, and 4.5.72+svn or something to that effect in the kde-unstable repos. Any suggestions so I can test just the new kdepim betas?

I'm installing prebuilt packages for Fedora13 from the kde-unstable repo using yum at this very moment.

Hey Sebas, thank you for the enlightening "Demystifying Akonadi" article. It was a great read and made me try the beta. :)

So I installed KDEPIM 4.4.93 and am now trying to compile Lionmail. Unfortunately, it does not compile with the recently released KDEPIM beta. It seems that it needs akonadiconsole from trunk, which was ported to KViewStateMaintainer with revision 1160389. However, I cannot just install the trunk version of it since some PIM parts were moved into other parts of KDEPIM. I wonder, though, whether akonadiconsole 4.4.93 (just released) is older than August 8 (the date of the port)?

In general, it would be great if there was a Lionmail that works with the KDEPIM betas.

Thanks,

mutlu

P.S. Here is the build error:

[ 54%] Building CXX object emailnotifier/CMakeFiles/plasma_applet_emailnotifier.dir/emailnotifier.o
/var/abs/local/lionmail-svn/src/lionmail-build/emailnotifier/emailnotifier.cpp:39:39: fatal error: akonadi/etmviewstatesaver.h: No such file or directory
compilation terminated.
make[2]: *** [emailnotifier/CMakeFiles/plasma_applet_emailnotifier.dir/emailnotifier.o] Error 1
make[1]: *** [emailnotifier/CMakeFiles/plasma_applet_emailnotifier.dir/all] Error 2
make: *** [all] Error 2

I'd need to copy the relevant classes into the Lion Mail sources in order to achieve that. These copied classes play a pretty important role in setting up the widget, so they cannot just be commented out. This time can IMO better be spend on finishing Lion Mail for its first release.

If you want to run it, you can either copy those classes yourself, or install kdepimlibs and kdelibs from trunk.

Thank you for your response, Sebas. Surely, you want your plasmoid to use all the available goodies of 4.6 since it won't be released earlier anyway. I think it is perfectly understandable that you made it depend on classes from trunk. I doubt I will actually install kdepimlibs and kdelibs from trunk since this is a production machine. Maybe I will have a go at copying the classes.

I any case, I am very excited about your work in this area. I have always been annoyed by the limitations of systray applets for GMail and other mail providers, and your work promises to overcome all this in the wonderful "silky" manner. You have real vision. Thanks for that.

Cheers!

For me migration is probably the most significant thing that concerns me so I'll step up and offer some time for testing. Thanks for raising the issue, Seb.

I tested the beta3 and still needed to return to the stable one. As everything else worked fine but it just was slow and every email what I downloaded were empty. Just showing from, to who and subject.

Need to fill bug reports to BKO.

I tested the beta3 in Arch Linux, too, with similar problems. The whole Desktop became *extremely* slow and unresponsive. Seemed to me that it was mainly a problem with very large local mail folders (several folders with >1000 mails), because with an empty set of the "local folders", it worked quite well.

Moreover, migration did non complete because of one of my imap-servers not supporting the UIDPLUS extension. Without a workaround found at bugs.kde.org I would not have been able to start kmail at all.

At least, I did not have empty emails - all mails showed up properly if you had enough time to wait...

If I find enough time for it, I will generate a test account in order to file some bug reports.

Also hit the UIDPLUS problem (on the university's Exchange server).

The bug report you refer to is:
https://bugs.kde.org/show_bug.cgi?id=236109 ?

So you can start KMail by removing the account, but then you can presumably not add that account without the fix in trunk?

Still, this is why we have betas... If the trunk fix doesn't make it into a released KDEPIM 4.5 then we'll have to make this issue very clear in the release info

I experienced the same slowdown, because Strigi attempted to index all of my mail and integrate it to Nepomuk. As a side effect, KMail/Akonadi became unresponsive.

When the indexing finished (I gave it an hour or two for ~20,000 mails), KMail/Akonadi and my system performance came back to normal. There's some optimization work that could be done.

I tried this release from Fedora and Ubuntu repos. The Ubuntu release (running on Maverick Meerkat) fails spectacularly with GMail IMAP accounts. OTOH, Fedora packages work great with the same GMail IMAP accounts (it does have bugs related to content display, but those bugs are evident, so they should be hammered by now)

I'm giving this warning because there's the possibility of massive bug reports against Beta 3 for a Ubuntu specific bug.

Edit: Also, if you are not running Ubuntu, you'll surely miss the count of how many times KMail/Akonadi is faster than the old KMail while handling IMAP accounts. To say "hundreds of times faster" is to underestimate the difference: with my GMail IMAP account, the sync time went from days (no kidding, it often took 3 or 4 days for KMail to get all the mail) to ~20 minutes.