During the Randa Meetings in Switzerland this year, the KDE PIM team decided to do an experiment. We wanted to see how modern QtQuick based PIM applications could look like. So we started to develop Kube Mail, an email client build with QtQuickControls on top of Akonadi-Next. We reached our first milestone this week. It is about time to show it to a broader audience. This milestone includes a read-only client, that loads and displays emails from a mail resource from Akoandi-Next. Here it is:
What you see is a bunch of QML on top of Akonadi-Next with the data being provided by a maildir backend. The mail list doesn’t do any partial loading so far, so we end up with ~4000 mails getting loaded, respectively the fields we’re interested in thereof. So what this nicely showcases IMO is the performance you get. Every click on a folder executes a fresh query and the list view is populated almost instantly. Of course this is still far from ideal with many parts to improve, but we’re rather happy with the result given that we just hooked up the UI for the first time.
We are working on a docker container for easy building and testing Kube but is not quite there yet. So if you want to try it, you need to build it by hand. You can find the source code in playground (akonadi-next; kube)
For now this is still an experiment but it is looking promising so far. We will continue working on Kube and build it into a small but functional email client over the next year. Drop by on our weekly hangout (every Wednesday 16:00 CEST) or write a comment below if you are interested in joining us. People from the VDG already showed interest, namely Alex L, Andrea Del Sarto and Jens Reuterberg. It is great to have their feedback in this early stage and we will work with them to ensure a great User Experience from the start.
Stay tuned for more updates.
mbohlender 
The main pain-points with Akonadi for me wasn’t loading mail dirs but was deleting. Deleting was super slow and locked up other operations(especially if it was a large amount of mail deleted). I also had problems viewing the mail while the client was checking for new mail. will Akonadi-next fix those painpoints? From what I see so far it looks good. I also like the minimalistic mail client.
Thanks for your feedback. We expect major improvements on the blocking UI issues and hope to get rid of them completely. As for deleting being slow: Was that a (disconnected) imap account?
For me it is the case with a pop3 account (normal akonadi, not akonadi next). Deleting a thousand mails or more takes minutes.
(…which also means minutes of high battery consumption on a latop).
But usually it finishes successfully.
Thanks for the hint. We can have a look at it once we get there. pop3 has currently a very low priority though.
I had imap / gmail before(and multiple accounts at that). I loved the integration / ability to draw in data and contacts from multiple sources like Facebook with Akonadi 1. But I would get emails and quite a bit and deleting them was a chore and sometimes I would do a search and go to delete all of the emails in that search result which could take even longer.
seems very fast, good job 🙂
Indecent proposal: do you think its current status (of akonadi next+kube) even if heavily work in progress can be packaged on the current plasma mobile phone images?
Dependency wise that should be within reach. Akonadi Next requires Qt 5.x, lmdb 0.9.16 (for all I know), flatbuffers, KMime (in it’s qt5 version) and KF5::Async (without KJob support is sufficient). Kube requires Qt 5.5 I think. We’re using a bunch of C++11 features, so you need a recent compiler as well.
The question is, I guess, what you’d expect from it. It’s certainly nothing that could be used right now, and the dependency list will probably grow a bit over the next months, so chances are that even if we get it to work, that it will break again on the plasma phone (but we definitely aim for portability and as little dependencies as possible).
Within the next few months we’ll probably start doing some experiments on other platforms anyways (windows, mac, possibly android), and that would probably root out some of the portability issues already.
So anyone is welcome to try build it on another platform, but in general I think it’s a bit too early for us to invest a lot in portability. But it would certainly be very useful to know if there are any blockers right now, so we can take care of them within the next few months.
But Kube on Plasma Phone? I’d love to play to see that happening =)
I guess I couldn’t decide between “I’d love to see that happening.” and “I’d love to play with that.” 😉
> The question is, I guess, what you’d expect from it. It’s certainly nothing that could be used right now..
I’m not expecting something ready to be used: but i’m expecting something that can be useful to both Kube/akinadinext and plasma mobile as a testbed.. to have a target built on a mobile platform during its development since as early as possible, I think it’s useful for the quality of the future product, both for kube and the plasma mobile platform.
Pingback: So what is Kube? (and who is Sink?) | Finding New Ways…