 Thank you. Thanks for coming. So this is going to be a rather non-technical talk. I want to talk about what we broke last year in KDPim and what we are going to break next year. So I just want to basically go through things that we did in the past year with other developers and tell you what you can expect from us in the next basically four releases. So the biggest thing in the past year for us was switch to KDPrameworks5 and Qt5. The KDPapplications 1508 a year ago was our first release with Qt5. It already included a bunch of performance improvements and we worked on the user experience as well and overall users accepted the new version quite well. We were surprised that we didn't run into many porting issues or bugs in general. There were some minor glitches, but I think we polished most of this by now and it works quite well. The other big thing that happened in the past year, it's actually in the last 16 await release was switch to Qt web engine. So the way we render emails and show contacts and even previews is that we just create an HTML and we show it in a web viewer. With the latest version of Qt, WebKit was deprecated and since email is one of the possible vectors of attack for attackers, we try to get into your computers and everything, it's better to have a rendering engine which is updated and secure. So we decided to switch to Qt web engine. I know distributions hate us for it now, but I think in the long term it will turn out to be a good decision. As I mentioned before, we use HTML a lot to show stuff because it's the easiest thing to how to present this kind of information like the event descriptions and details about your contacts. So in the previous versions, we used to just have a C++ code that would randomly assemble the HTML from strings and put the proper values in the middle. It was almost impossible to maintain, so we slowly migrated to Grandly. Grandly, if you don't know it, is a Qt library for HTML templates. So you basically create an HTML file where instead where the actual values should be, you just put some placeholders and then you ask Grandly to load the template and you give it a map basically of the placeholders and what actual values it should replace it with. So this allows us not to only have natural HTML files which are very easy to maintain for us, it also means that in the future we can introduce something like custom templates provided by users. So if you don't like how your emails look like now, you could easily write your own template and use it and possibly even share it with others through the KDE store. The biggest thing that we've been doing in the past year and another reason why packages hate us was that we've been reorganizing the Git repositories a lot. If you remember the KDE four times, we used to have basically four core repositories that was Aconadi, KDE PimLyps, KDE Pim and KDE Pim runtime. We decided that it's not enough, so we now have this. Just as a matter of fact, this is around 60 repositories of KDE Pim code. The entire KDE frameworks are around 70 repositories, so you get the idea how big project actually is. The reason why we decided to split it like this is that basically the reason is similar like it was with KDE Lips and why it was split into frameworks. We had lots of fancy things in there, but nobody could really use it. If you wanted to use our parser for contacts, it would depend on KDE PimLyps, so your application would also depend on the entire Aconadi thing and you would get also calendar parser and all the other stuff you didn't need. We worked on splitting these things. Right now we have lots of repositories. The Aconadi thing, which was basically split into the Aconadi repository and KDE PimLyps repository is now merged. Everything Aconadi is in Aconadi repository and we now have a bunch of fancy libraries that might be interesting for application developers. We have Kcalcore, Kcontacts, and Kmime, which are libraries for parsing Vcards and iCals and email messages, and you can use them standalone and they have very little dependencies. This is something that some applications have been already using in the KDE for days, but it meant like DigiCam was depending on KDE PimLyps because of that, or Copeta as well, which is silly. Now they can just pull these individual libraries and use it nicely. K-Holidays is another very nice library that provides an overview of national holidays and bank holidays in almost all countries around the world. We also have libraries that implement various protocols, so we have KMUP, KLDUP, which implement the individual respective protocols. There are much more libraries in there. I will not go into everyone, to all of them. You can see on the first column that's KDE, what we only split it from KDE PimLyps. KDE PimLyps is no longer being released. There's nothing there in the repository anymore. Recently, we also split KDE PimRepository, so the middle column, that's a list of applications we have now. That's not interesting. What's interesting is the last column, which we have a bunch of libraries that were not in KDE PimLyps, they were sort of in KDE Pim, but only by the PIM applications because we didn't feel like anyone would use them, but then we realized, oh, that's actually some cool stuff. We have Grandly Theme library, which we created because when we switched to Grandly, which I talked about a couple of slides ago, we realized that Grandly is missing a few things. Grandly Theme actually provides us with some neat Grandly KDE integration, so it introduces new tags into the Grandly theme, like you can use, you can load icons through Kicon loader just by saying the name of the, use the icon tag and the XDG name of the icon and the plugin can load it, which makes it much easier for us. There's LibGravatar, which allows you to easily pull avatars from the gravatar and Libre avatar service, basically the free version of gravatar. And we have LibKC, which, similar to KIMap, is an implementation of the CIF protocol, which is a filtering protocol for IMap. So yeah, we have now lots of repositories, but this was the final split. There will be no more repositories, and we hope that eventually we will be able to move some of the cool stuff into KDE frameworks. So for instance, DKCalCore and similar repositories would be, would be reliant to have them in KDE frameworks with all the API and ABI stability promises and making that available to even wider public. Now to the individual programs that we worked on. So obviously KML is probably the most important part. That's where most of our focus goes on in the terms of application development. So we have improvements in accessibility. That was a long-term complaint that the accessibility of KML wasn't very good. Now we have text-to-speech integration, so you can actually listen to your emails, either because you want to or because you can't read them. We have some really good performance improvements when it comes to threading. So if you follow some flame war heavy mailing list, and you get lots of very deep threads, it takes forever to open. So we now have caching for the threading, so we don't have to calculate how the email goes to the threads, and we just load it from a file, and it's much faster. Some really tiny useful features which are very well hidden in the settings, but if you can find them, you actually figure out that we can do lots of clever things now. Like for instance, if you have the problem, like I do, I have a bunch of email identities. So I have my work account, my atKD account, my personal email, and I constantly keep sending emails to people from the wrong identities. So in KML now, you can actually bind or choose that if you are sending email to a specific domain, that we should use some specific identity for that. That means, for instance, if you can choose that, if you are sending an email to atKD.org address, you always want to send it from your atKD.org address so that you don't accidentally send it from your work account or personal account. The nice things we've seen in a couple months, maybe the last two months, was a tiny influx of new developers, like occasional contributors. I think there were two or three guys who sent random patches improving the search and stuff like that. Loran also spends some time on AcroCator. AcroCator is our RSS reader, which has been neglected for a very, very, very long time. We also switched to Key Web Engine as everywhere else, but that is still being worked on. We have a lot of bug fixes in there. As I say, we basically haven't fixed anything there since the switch to Qt 5 and up until now, so the last release of AcroCator is pretty good again. It was also one of the places where we saw one or two people stepping up from the community and contributing some improvements in notifications. One of the things that was most requested in Plasma 5 since the beginnings of Plasma 5 was the calendar integration. Plasma 5 since the beginning was on all the fancy screenshots, they were showing the calendar agenda view, but it was always empty because there was no integration with any events back end. Now finally, with Plasma 5.7, I believe, there is an API that allows third parties to provide a plugin that can show data in the Plasma calendar applet and with applications 16.08, so the last release of KDE applications, the KDE PIM, so it also ships the plugin that will feed your events from KOrganizer into the Plasma applet. This is probably the biggest project that is happening now in KDE PIM. ECGPG is actually funded by the German government for us to work on. The idea is to get mail encryption and mail signing to normal people, normal users, people who don't know what cryptography is, what asynchronous encryption means, sorry, asymmetric cryptography means, what keys are, so the idea is to make this easy for them, basically transparent. Don't butt them with crypt algorithms and key sizes, just make it as simple as possible. Currently, we are in phase one of this project. What we have right now is, when you create a new account using the account wizard, you can also choose if you want to enable mail signing and mail encryption by default. And if you do so, in the next step, we will just use the name and email you already provided, and we generate a new key pair. We just ask for a password, and then we automatically publish the email to the new KnoopG key service. And this all happens basically without the user having to understand any of the things behind this. We also set the keys to the identity which is created for the user, and so when users try to send their first email, the email will automatically be signed. Then we also improve encryption, so when you are sending email to someone, you need their public key so you can encrypt the email that you are sending to them. This also meant for users to actually either know that they need a public key, or they would have to know where to go and find the key if they didn't have it. So we also improved on that. Now, when you type in a recipient address into the Composer window, we simply ask the KnoopG key server, fetch the key if it's available, and we show a little hint saying we will send the email encrypted to this user. And the user can just, the sender, you can just decide, I don't want to encrypt really, and you can disable it, but by default, you basically can send encrypted email to everyone without having to care about all the key stuff. The encryption for now is disabled by default. You have to enable it manually, but once we have some more stuff in place, we will enable it by default. This is all building on the TOEFL concept, so trust on first use, which means that basically you don't need to go to signing party to get your keys verified, because only geeks do that, normal people don't. So we base on the idea that if you receive a certain amount of emails from the same person using the same key, then the key can be trusted, and the more emails you receive, the more we trust that key. And we built on this, so basically, now when you get an email, you will most probably get a yellow frame around the email saying this key has unknown validity or we could not verify validity of this key, but does that even mean, right? So we just say, this email was signed, and we believe that it was signed by the right person. So people don't really have to be confused with this terminology. Right. I pulled some numbers from the Git repositories and from Baxila. The numbers are not precise because of the splitting that was happening. It's hard to track comments when they were being moved between repositories, but it should readily add up. So in the past year, we had 64 individual contributors, including scripty, so 63 human contributors. These 64 human and non-human contributors made over 8,800 commits, which sounds pretty good, right? The project is healthy, it's being actively developed and maintained. The developer base is quite big. Yeah. Well, there's a catch. 72% of these 8,800 commits were done by a single person. That's Loran Montel. That's the only person who can every year beat the automated scripty bot in number of commits. And in total, 90% of these commits were done by only five people. So yeah, we have a lot of, like, one-off, one-on contributions, but most of the work is done by a very few people. And you saw how many repositories and code we have, so we are really struggling to actually keep the quality high and keep introducing new features and new stuff. So if you have lots of spare time, which I'm sure all of you have, please help us. Though we managed to fix a few bugs, so we fixed about 324 bugs. At least that's what bugs the bug claims. I think it might be more, but yeah. So that was the overview in numbers. Now let's look into the future. We will be adding even more and even cooler crypto stuff. So when I was talking about the easy GPG thing, I mentioned it was phase one. There's obviously then also phase two coming in eventually, hopefully sometime in 2017. We want to work on actually making more or less secure storage for the emails locally. That means that there will be an option for users to choose that when an email arrives, that they want to store it locally decrypted. So if the email comes encrypted, we can decrypt it as it arrives and locally decrypted. The advantage of this is that we can index such emails when they are decrypted and then you can search in it. If you get lots of encrypted emails and you remember you've seen something in one of those emails, you have to actually go through them manually because we cannot index encrypted emails right now. We don't see into them, so we cannot index them, so we cannot search in them easily. So assuming most people today use encrypted hard drives anyway, so you don't need another layer of encryption on top of that. So we can easily just decrypt the email as it arrives and store it locally, decrypt it and index it and do all other kinds of fancy stuff with that. These features should also support the work the other way around, making the storage more secure. That means every email that would arrive would be decrypted with your keys and would be stored locally and encrypted. That is probably for people who are very paranoid. But those are the roughly plans for the next crypto work. Obviously, we will be also working on improving Cleopatra, which is the key management application in KDPim. The usability of that application is questionable at best, but so we want to improve it to make it, again, more accessible to regular users. They don't have to go in there. That's the idea of easy GBG. People won't actually have to open Cleopatra to manage or work with their keys, but sometimes you have to and then we want to make it easy for them to work with it. Loran has some plans on changes in search. He doesn't know what exactly he wants to do. He just mentioned he wants to do this. My plans at least were to improve the infrastructure for searching. Right now, searching is rather fragile. It usually finds stuff you're not looking for and doesn't find the stuff you are actually looking for. We want to improve it, make it more robust, make it faster. We would like to improve the UI, which I think is what Loran wanted to do, because now there is a search dialogue, which is complicated. You can build complex queries, but it's also complicated to use it, so we would like to simplify it. In the past year, we've been also working on stripping down the features that we have, because KML has about 500 features, plus another 300 that are in the code, but no one can find them in the UI. We are working on actually making them optional as a plug-ins, so we have quite a few things in the KDPM add-ons repository, which are optional plug-ins. We would also do a bit of facelifting to contact, because contact looks the same for the past, I don't know how many years. It's hard to really change anything. I mean, you need a list of folders, list of emails, and the email, but I think we can present it in a nicer way that is more modern, maybe closer to what the modern web interfaces do. We would like to look into this as well, and we would like to streamline the account creation and account management. Right now, your accounts are basically split into three places, and in each place, you configure something slightly different, so adding a new account is pain, and we would like to have this in a single place. I really like what Thunderbird does, so we might get inspired in there. Finally, something we realized very recently is that we've been working on something, and we don't even know what people use. I mean, what parts of contact and KML people use, how they use it, how many accounts they have, how many emails they send, do they use IMAP, do they use POP3, do they use MailDir, do they even use the other applications? Does anyone even use K address book? Why would you? The idea is to create a survey with lots of questions and try to get it to as many people as possible and figure out what our users are actually interested in. We will be discussing this on the buff on Monday and then with a bunch of the other developers the week after that, and then hopefully maybe next month we will publish it. So if you see a KDPim user survey, please help spread the word so that we can get input from as many users as possible and get some idea what we should focus on the most so that we can improve the KML in a way that helps our users and not just ourselves. Finally, there will be a KDPim buff tomorrow at 3 p.m. in the room Mara003, whatever that is, but we will be there all afternoon, so if you want to get a bit more technical about contact and KDPim, you can stop there and talk to us there. And I believe, yep, that's it. Thank you. Hi, I would like to ask are there any plans to re-strike the support for Microsoft Exchange? There's no contact suit in Akonati. I mean, there were a few efforts a few years ago, I think they never got finished, but I think it's a very big thing that still keeps many people from using it in the workplace, for example, since we have an exchange server that does not allow IMAP or can only do it for mails, not for contacts and for calendar data. So any plans in this direction? Not as far as I can tell, but we can put it on the never-ending to-do list of things to do. Sorry. Other questions? Maybe it would be good to ask people why they do not use K-Mail, perhaps because of the repositories, because of the dependency hell or maybe because features are missing, just an idea because it cannot be there tomorrow. Think about it. I don't think the number of repositories is something that concerns users. Most of the distributions, as far as I know, we're already doing this split on the packaging level anyway, so now we just make it easier for the packages to actually package individually. It's just more packages for the release team to release. And yeah, good idea with the asking what they are missing. That's a good thing to add. But I'm sure we have all the features already. We just know what we managed to find them in. Dan, I'm a packager. I hate you guys, but we are done. No more splitting. And that makes me very happy. Thank you. Yeah, I'm a packager too, so yeah, I hate myself as well. Seems like PIM developers are a bit of a masochist. Any other questions from the room? Yes. So I'm one who runs K-Mail regularly from master, including all the dependencies built, and I regularly have problems with the regressions in the master build, which is very annoying if you depend on your mails on your workflow. So are there plans to ensure better that there are no regressions, especially now that the splitting is done? Yeah, well, having a unit test would be nice, but the compilation issue is it escapes us. I mean, there seems to be something with CMake, we believe, that it keeps looking for all libraries that no longer exist, even though you updated them. I have the problem as well. Not sure what the problem really lies. The breakage of stuff, yeah, our unit test coverage, unfortunately, is luck it get best. Yeah, I think we are still in the phase where we keep doing bigger changes. Which tends to break while Plasma and Frameworks are now doing smaller incremental changes. So it's much easier for me to break things now that I can change things like really big changes. There are still a few in the pipeline, so there will be some more instabilities in master for at least the next half a year. Seems like there's plenty of discussion going on that will populate your buff then. If there are no other questions, let us thank the speaker. Thank you.