Summer of Code and Social Desktop

I’ve been thinking about Google’s Summer of Code program a bit, and since it’s having its fifth birthday this year. I thought it would be about time to congratulate the people at the Open Source Programs Office in Mountain View, especially Leslie, Cat, Tiff, Erica and all the others who I had the pleasure to meet at various occasions. Good works, gals!

From a KDE point of view, it’s nice to see after 5 years that this Summer of Code works. “Works” means that it does get us a lot of attraction from new talent. There are actually quite some people active within KDE on a regular basis that have found their way into KDE through the Summer of Code programme.

It’s good to see how this is managed by the Google staff as well, they’re not just throwing money at us, they’re actually putting a lot of effort into SoC, and it provides real, tangible and sustainable benefit for Free Software projects. That’s money spent well.

The user wins as well, over the past year, we came to ship many of the things that have been done within Summer of Code project. In Plasma for example, there’s the extenders that have been introduced with KDE 4.2 and has already become part of the core infrastructure. Rob Scheepmakers is the guy behind extenders, and has since then maintained the codebase and improved it further. Then there’s of course Chani, who has also “landed” her Summer of Code project in KDE 4.2. Her project brought plasma widgets to the screensaver. Something I wanted to start using on my desktop machine yesterday so I can suspend it without needing to unlock it first. No dice, turns out it’s not as straightforward as I thought (i.e. it would take me more than 20 seconds, which I didn’t want to invest at this point). It’s probably about 4 lines of javascript as well. I’ll buy the person that does it a beer during Akademy on Gran Canaria.

This year, I might mentor a project. There’s the Social Desktop proposal. I thought I had added it about a week ago, and wondered why nobody got back to me on that. Turns out that it hadn’t actually been saved probably due to an error on my side. I’ve added it again, and now it actually turns up on the page. I think there are still a couple of days left until the deadline, so maybe someone comes up with a good proposal. I can help a bit by giving feedback for a draft, so you can still get it into good shape before the deadline.
The Social Desktop is actually a very intereting project. It possibly combines many of the interesting KDE4 technologies in a way that should be tangible for the user. Code-wise, it will mostly happen on a rather high level. Part of the work will be integrating the bits that are already there, Decibel for real time communication, Nepomuk for search and indexing, Akonadi for PIM data, but also more “web-enabled technologies” such as GHNS, JOLIE and Attica to get information, content and also more interaction between users going. Update: So turns out that my space-time continuum was out of balance when I wrote the above lines late last night. I had been looking at the 2008 page, and assumed my social desktop idea wasn’t there. Some friendly people pointed out that it is 2009, and after a quick check (we have clocks for that in Plasma), I have to concur.

What’s up with Lion Mail?

Lion Mail Plasmoid.
With an Akonadi sprint in Berlin coming up, I thought I’d write a couple of lines for those who are interested in some PIM stuff in Plasma.
Lion Mail is a Plasmoid that shows information about emails. It can be used to display for example unread emails in a popup in Plasma. Lion Mail is much more powerful than that though. Lion Mail can load various collections, and handle them as independant applets or groups of applets on the desktop. It uses Plasma’s extenders which provide support for detaching parts of an applet. Lion Mail offers in fact two Plasmoids. The Lion Mail applet groups emails into collections and displays them in a configurable listview, either on the desktop or as popup applet in the panel. Then, there’s the emailmessage applet that can be put in either panel or on the desktop, and reveils more information as you make it bigger. It dynamically loads the body and displays it if you give it enough space by resizing. This happens transparantly for the user. The idea behind this is that you can drop interesting emails for reference onto desktop or panel, and throw them away when you don’t need them. The email applet also offers interaction buttons. You can flag the email as new, unread, important and task item right now. I’m planning to also offer a safe way to trash an email, so you don’t get to end up with the situation where you’re distracted once by some spam email, Lion Mail and the Email Message Plasmoids act as some sort of intermittent email reader.

The third and least visible part is the Akonadi dataengine. It’s actually there for a long time already, but hasn’t been much used. I’ve picked it up, brushed a bit of bit-rot off of it and extended it to do everything I need, and a bit more. I’ve also added support for contacts to the engine. Having a dataengine for this kind of stuff means that the data is very easily accessible for scripted applets, no special bindings for libraries in PIM or Akonadi are needed. (Naturally, the dataengine itself uses those libraries internally.) In the screenshot, you can see the configuration dialog, the Lion Mail applet and an email applet, all placed on the desktop. The Lion Mail applet show a list of emails, with various bits of metainformation hidden or shown. As you can see, you can even view the full email from within Lion Mail. The buttons shown let you tag the emails, or mark read/unread. Clicking on the icon expands and collapses the header, clicking on the green expander shows and hides the body. It’s loaded dynamically from Akonadi. Typically, you’ll have Lion Mail sitting in your panel, if you click on it you’ll see a popup just like the right applet in the screenshot. If you’re using the email applet on the desktop (bottom left in the screenshot), you can reveal more information by resizing it using applet’s handle.

There are a couple of things that need more work, either because I’ve not gotten around to it yet, or because I didn’t find a good solution. In random order:

  • Various layouting bugs. Qt 4.5 has improved the situation quite nicely,
    and along with it my experience and wisdom of QGraphicsLayouts has increased a bit as well. Still there is something I’ve not completely sorted when displaying the applets in a list and expanding items in that listview (usually Lion Mail).
  • Fetching the list of collections from akonadi often takes 20 seconds,
    I’m not sure why. Fetching individual items is pretty darn fast. Fetching of all the lists and content from Akonadi happens fully a asynchronous, which is a big, big plus if we want to keep the UI responsive.
  • Drag and Drop support. It works in a wacky way from Lion Mail onto the
    desktop, but needs a cleaner solution. I’ve already called onto the gods and demi-gods of the holy Plasma to get me ideas. The issue is basically that we’re not dealing with email data but with URLs that deliver us one content type or the other. Checking the mimetype of some dropped URL and doing something sensible with it is something I didn’t get to work nicely yet. While the current code is totally disgusting, it’s pretty neat interaction-wise. Upon dragging an email, you get a nice large-ish email icon attached to your mouse cursor, and when you drop the email onto the desktop, it’s created from the akonadi URL, and loads its content from there. Eventually, the user should be able to just drag an email from her favourite email client (Mailody for sure, it’s the first app to use Akonadi for email) onto Plasma, and maybe the other way round as well.
  • Sorting and more advanced querying (“virtual folders”). The way Lion Mail works right now, it’s not possible to sort emails. I’m not sure how to solve this best, since it’s two things I want. First and foremost, I don’t want to request full folders of emails (a couple of thousand emails in the common case) only to throw 99.9% of them away. That means that I need some way to query “8 news unread emails from all folders” or “all emails flagged important from imap folders private, work”, “emails tagged ‘petting zoo'”, “8 latest emails from Artur, Wade and George (Yes, you George!)”. That’s the kind of thing I want to be able to display with Lion Mail. The other side of the problem is of course that the display in Lion Mail itself doesn’t do any kind of sorting at the moment. I figured that would be futile, since I’m using the “throw away 99.9% method” right now anyway. (WTF++) Something that needs more of that tender, love and care. And probably some model-view-akonadi-fu as well. (I’m looking at you, Till. :-))
  • Integration of activities. The collections shown may vary depending on the current activity. It should be straight-forward to set up Lion Mail so that it only shows you emails relevant to your current activity. Or in less abstract terms: When you’re free, you should be notified and shown emails from work or when you’re working on some project, to show emails relevant to that context. One of the TODO items.
  • Notifications. Didn’t get to that yet, simple as that.
  • Improved display in the panel. This means for example showing the number of unread emails in there, or something more fancy than that.

I’ll meet bright people at the Akonadi meeting in ten days at the KDAB offices in Berlin, and that I’ll find solutions for some of the things that I want to do in Lion Mail. Developer meetings are a wonderful way of learning and tapping into other’s knowledge and experience. Or simply to get someone to test it and see where things are breaking and falling apart. :)

Another couple of ideas I’m planning to implement for Lion Mail is more integration with Contacts. Here I’m not necessarily talking about “entries in my addressbook” (only in the ideal case, where they actually have an entry in my addressbook). A contact goes further than what the entry in the addressbook provides. Contacts are one way to provide context to data. The sender of an email matters a lot, even more so when you’re looking at emails. Other emails by some person are probably relevant to show as well, pulling in instant messaging status, and possibly social network activity are surely interesting things to look at. Hmm, … “Lion Mail: Social Networking for Email Geeks”. sounds like a nice vision statement for it. ;)
For that to happen, I need to figure out a way to ask Nepomuk about data related to the concept of a “Contact”. The exact relationship is a bit unclear to me right now though. Should all data be requested through Nepomuk? In how far can I use Nepomuk concepts in Akonadi? Think of the famous “give me all items (emails, chat logs, …) by this Nepomuk contact”.

If you’re interested in looking at Lion Mail code-wise, it’s currently in Plasma’s playground. If you’re planning to use it, hold your breath for a while, it’s not ready for use at this point.

A nice side effect of all that hacking is that I’m starting to get the hang (addiction?) of the Monster that C++ can be. I’ve started learning C++ about two years ago. Over the last weeks, I’ve felt that I’m more confident with how I write code, I make less dumb errors, I understand more quickly what’s going on, and I can understand code quicker now. There’s so much more to learn, but at least I’m feeling I’ve moved from the “figuring out how I express this in C++” to “write code” mode. That said I’m all but an experienced C++ hacker. One of the things that continue to strike me is the overall clarity of KDE’s codebase. Combine that (providing huge amounts of examples for everything) with a lot of nice people that can help you figuring out things, and you get a very productive and rewarding learning environment.
Of course I’m not even talking about touching non-Qt/KDE code. That still is something I generally try to avoid, mostly to keep complexity down to a level that is manageable for me. And it’s icky.

Bossa conference 2009.

Bora Bora beach near Recife.
I’m in Porto de Galinhas near Recife in Brazil right now, where I’ll be
keynoting at Bossa Conference later today. I’ve been flying in last Thursday from Amsterdam via Lisbon, where I already met some Trolls (Andreas (QGraphicsView), Marius (QItemViews) and Simon (QWebkit)). After a good flight (I got four free seats in a row, which translated to “lie down and sleep as much as you can” to me), we arrived in warm and sunny Brazil. It’s about 30 degrees here, and it’s spot on summer (spot on winter would mean 26 degrees C, since Recife is only 8 degrees south of the equator). On Friday, we visited the INdT office close to our appartment, and on Saturday the iNdT guys took us to Bora Bora, a piece of beach 2 hours south of Recife that welcomes you to paradise. Can’t really argue with that. :-)

On Sunday, the “conference improper” began with a welcome and drinks in the evening so everybody was able to have a fresh start on Monday. Sandro opened the conference with being interrupted by a bunch of Brazilian dancers, I guess everybody was pretty much awake after the drums on dancing.

The conference itself strikes a very nice balance between interesting talks, interesting conversations with interesting people, all that in a very relaxed environment. It takes place in a beach resort, basically a small village with a large swimming pool landscape in its center. The conference and hotel staff is making sure that everything is running smoothly and nobody seems to miss anything.

An interesting talk I followed yesterday was Marcel Holtzmann’s
presentation about ConnMan, which is a new piece of infrastructure for “getting online”. Marcel went through some parts of the network stack showing many parts that just aren’t up to today’s requirements anymore, and presents a solution that he’s currently working on as part of his work for Intel. ConnMan is a replacement for NetworkManager, which is built to be scalable for the future when new technologies such as WiMax arrive at the user. It’s basically supposed to be a “more than full” replacement for NetworkManager, which is very complicated in its design and often very slow in its use. ConnMan is designed to make it easy to build a UI on top of it, which is good news for people like me, having worked on the NetworkManager plasmoids UI bits. While I was at first rather sceptical, thinking “Now that NetworkManager actually starts to behave like I want it to, it’s being replaced, oh noooooo!”, Marcel’s managed to convince me that the way forward he’s proposing is actually very sensible. Will Stephenson will probably concur as he sees actual documentation, as he’s been the “sucker” who took on the work going through large parts of NetworkManager’s source code to find out how to write a UI for it. Let’s just say “it could’ve been a more pleasant experience” ;-) So yeah, documentation on the interfaces is something critical if you want others to use your stuff.

I had some interesting conversations yesterday with Rasterman, the founder of Enlightenment. Topics ranged from resolution-independant interfaces to release policy, filesystem hierarchies and how that works for users and of course more mundane subjects like “cocktails served in coconuts”.

The atmosphere is is really great, it’s fantastic to discuss plans and their implementations with the iNdT folks (especially when the meeting table is not a table but a large swimming pool — that definitely makes for fun and interesting digressions.

In unrelated news, Gökmen, one of the developers of Pardus Linux (a Turkish Linux distribution) has invited me to speak at a (more user-oriented) conference in Istanbul next month. I’m happily accepting that invitation, so if you’re in Istanbul on April 17 and 18, make sure you drop by.