As you all might know or not, KDE is moving to git. With applying for an svn you had the option to choose for a https account with a password. With the move to git now in high gear we have to convert all those accounts to ssh accounts.

What will happen is that we will send every https user personal invitation to go a to a webpage. On this webpage you can upload your public ssh key or indicate that the account should be disabled, because you don’t use it anymore.

The invitations will be send in like two weeks. Every invitation that bounces will probably mean that the account will be disabled. So we can not stress enough that you check your email address which is associated with your account. You can find it in kde-common/accounts. You can simply do a checkout and commit changes to your own entry.

Ssh users dont have to do anything, your public keys will migrate automatically. Https users, please wait for the invitation, as we will automate most of the process to move you from https to ssh. So there is no need to request the move from https to ssh at KDE’s sysadmin, unless you are developer of the first couple test projects.

Advertisement:
This post is made on my new N900, with the MaStory app, wich is a totally cool app on a totally cool device. I just had to tell you :-)

The last days I worked on the accountwizard. This will be the assistant that new users automatically see when they launch KMail for the first time.

I’ve changed it in a way that it wil automatically retrieve the correct settings for the incoming and outgoing server if they are already known.

I’ve blogged about it the last few days, so I won’t redo the details, I just wanted to show the final result. The video shows a kmail without accounts, than I launch the accountwizard, give my details for my (unused test) gmail address and the rest is done automatically. You can see the accounts are configured and KMail shows the account in the folderlist. We can’t make it easier I guess :)

Direct Link to the OGV.

Day 2 ended with a little bit of pleasure. It all started when Matthew was trying to input some text to his laptop in a way where he treated his laptop more like an old fashioned typewriter. Making a lot of noise and finally banging his fists on the table out of frustration. Thomas then asked on a very interested and calm tone ‘So, did it work out?’. After that we used the beamer to look at all the Knut Yrvin YouTube movies and of course we replayed the Qt4 dance while we were there. We decided that it was not as much fun as going to the karaoke bar with Aaron, but it came pretty close :)

After the couple hours sleep (’Is this good for productivity in any way?), we started the last bit of the API review. We reviewed the akonadi changes between the KDE SC 4.4 release and current trunk, renamed method names, watched for const’s and made sure we did not do any binary incompatible changes.

After lunch, we had a small talk about deprecating all old API KDE has which deal with kresources. As Akonadi is the successor of those and that is approaching rapidely, it is time for developers to port all the remaining kresources usages. With marking that API as deprecated, they get nice little warnings while compiling….

After that we talked a bit about the development of kdepim in the next months, where in SVN that will happening, and how that matches the KDE policy around the upcoming freezes. More news on that later. We first need to talk to some more people.

In the meanwhile I adapted the accountwizard to the changes i described yesterday. And with good progress. We are now beta testing it and fixing the remaining bugs. Should be ready for the KDE-PIM 4.5.0 release.

Steven hacked on unit tests and proxymodels (what else, whahaha). Tobias fixed most issues brought up by the API-review and some small fixes in KAdressBook (of course). Volker fixed a couple of KMail bugs, answered loads of questions and stated just now ‘Now that you asked me, i did not really do that much’.

Kevin Krammer worked on the conversion tool for transferring the old data from kmail to the new akonadi based akonadi. It has challenges like reading the old cache folder, which can contain a mix between mbox and maildir files and directories. He promised to blog about that later on.

Sérgio spended his time on KOrganiser, fixed a bunch of bugs and made the journal editor working again. Matthew fixed the default layout for KMail and a bunch of bugs, for example he fixed the hated bug about the ‘kontact special date summary plugin’ (if scrabble had spaces, this would have been a winner) hang now and then. Now ported to Akonadi properly.

Thomas deprecated the KResources API and bugxing and porting on KMail. Kevin Ottens worked the past days on the kimap implementation, writing unit tests, heck a whole framework. Users can activate a logfile to provide debug output about the imap process. That logfile can then be replayed with his framework, to exactly reproduce bugs.

You can see, that we are working in very many area’s at the same time. preparing our software for the next release. More tomorrow…

Day 2 started early, especially because I could not get to sleep. I always have that when I’m hacking late at night, my mind goes in super active mode, and that needs some time to return to relax mode. Anyhow, we started with the Nokia guys, discussing how we can incorporate their BIC changes to KCal manageable. Basically they now have ended up with a fork of KCal, and they insisted in solving that, and of course we want that too. Basically we came up with a proposal where the KCal Core will be shared by both and there will be a special part that fits the special needs of Nokia/Meego, which will be maintained by them. That’s the part which ‘we’ don’t need basically. Fair proposal I think. I was pleasantly surprised by their willingness to work with us and making sure the fork will not remain in the longer future.

After lunch we started fixing bugs.For the first time in a while we managed to sync with my imap server. It is so stupid how tiny little things prevent huge things from operating properly. Change a few bits and everything starts to work again. It is so great that at such a meeting everyone is available, we have the imap guy, the akonadi guy and the guy with the problem. there is no escape possible, a solution will be found.

After that I actually was able to run KMail, saw that it wasn’t as bad as I had made it in my mind, and even fixed a tiny bug in there. Imagine that, me fixing bugs in KMail. Don’t get used to it. The rest of the day was filled with everyone hacking and fixing bugs. With this speed stuff should get working for a lot people Real Soon Now.

My blog about accountwizard triggered some nice comments. Some people pointed out security issues, which we had not given much thought, and some people also pointed to Mozilla’s ISPDB. I’ve read the documentation, which is conflicting here and there and unclear in some area’s, but I was pretty quickly convinced that was the right way to go.

I started to create code which can communicate with ISPDB and finished that just now, pretty straightforward overall. The idea is that the user provides his e-mail address and in that will be checked in an online database. If it is the database, the proper settings for that provide are returned. Exactly what we wanted to do with the GHNS integration. The mozilla team has setup some security measures to make sure no attacker can upload malicious scripts. So using that makes sense.

The next days I will adjust the accountwizard to first use this ISPDB primarily. Needs a bit of re-factoring now, but that’s ok. Stay tuned….

In my las blog, I promised that I would explain a bit about what I did manage to work on the last months. A while ago, we all agreed that the account configuration as we all know it in KMail is not the most user friendly way of communicating to users. Providing options for TLS / SSL / CRAM-MD5, etc. We know most people don’t understand it at all and it gave a lot of fuel for bugreports.

This resulted in Volker writing code to make this wizard based. You ask the user what there full name is, etc. guiding them though the whole process. He also made it so that it would be possible for providers to provide a wizard on their own. That means providers could provide a script which only asks the needed information and fills in the other needed data. Like TLS / SSL / CRAM-MD5, etc. They obviously know the correct values to connect to their servers, and it leaves a limited set of questions the end user has to fill in. In the most ideal situation only their username and password.

While Volker did all that work, I kind of picked it up where he left it and decided this system would be an excellent candidate for get hot new stuff. My idea was that these provider based scripts should be downloadable by the end user, although I wanted it to be transparent. That means that when the user enters the wizard, it asks: which provider are you using? The list with providers is automatically fetched from the ghns-server and displayed. If their provider is not available they will be ale to enter the account details manually. That’s now implemented, see this screenshot.

What will strike your attention is, that there is only one provider available. So true. And that’s where my new project will kick in. I want to automate this process. In the idea work flow, the very first user of a provider will have to enter their data manually. After this process it is possible to use that account to create a new template script for that provider, and upload it back to the ghns-server. The second ever user immediately sees that new provider in the script and only has to fill in just a few details. Of course we will do so for some well know providers like gmail, gmx, etc.

What’s particulary interesting in this setup is that the provider wizard are scripted, that means it uses kross and the files are javascript. So each provider can provide their own scripts without needing a development environment or knowledge of C++. Everyone can do it. Companies can provide their own wizard for easy setup for new employees or whatever….

I hope to get started on this somewhere during this meeting. If you want to help, jump in the #akonadi channel. I probably need to create the foundations of this application first, after that help is appreciated, as I probably become distracted again soon after the meeting is over.