I’ve written an article about KAuth, the new authentication framework in KDE SC 4.4. Earlier today, Linux-Comminity has published it. Go and read it (if you understand German) :)
January 23rd, 2010
Good News for multiple battery KDE users
Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.
Not anymore! Now I’ve got this second battery in the optical drive slot of my dear Thinkpad T60, I can immediately identify problems with displaying the charge rate of more than one battery, and I did. One bug displaying a wrongly formatted translation string in the battery’s popup has already bitten the dust, within one hour of delivery of the second battery, I committed a patch to the 4.4 branch and trunk of KDE SC. As far as I can see, showing the charge rate of multiple batteries basically works. I’ll probably find more room for improvement as I use this new setup, but for now, rejoice!
January 7th, 2010
KDE SC 4.4 branched, trunk reopens
So tonight, release-team-hero Dirk has branched off KDE SC 4.4 from trunk. Let quickly explain what this means. Trunk/ is a directory in KDE’s SVN repository, the central place holding where all the code from different contributors spread across our planet comes together. In a big team like KDE, we need some coordination to be actually able to release our software packages once in a while. Since the release of KDE 4.0.0, a typical KDE release cycle takes 6 months. Roughly 4 months of development, followed by about 2 months of stabilization and testing towards a release. In the stabilization period, which starts with the feature and string freeze, only bugfixes and code improvements are allowed. This is also the period where we release regular test releases, in our case a beta1, right after the feature freeze, and a second beta (happened shortly before christmas). The next test release is coming soon, which is -rc1.
This time around, we have slightly changed the original schedule. This made it possible to depend on Qt 4.6 with KDE 4.4. Between the release of Qt 4.6.0 and KDE 4.4.0 needs to be a bit of time. The release brought a lot of changes and new features, so a bit more testing is in place. In a complex software stack like the KDE one, there’s many cases you can only find and fix with enough people running it. So we inserted an additional two weeks, which makes us align nicely with the new Qt, in fact there will be a Qt 4.6.1 available with a number of fixes that are pretty much essential for running Plasma and many KDE applications, like global shortcuts which has been a problem recently (a fix for that will be in 4.6.1, Thiago told me). We’ve inserted another release candidate, so there will be an -rc2 before KDE SC 4.4.0 is out, as you can see in the release schedule. KDE SC 4.4.0 will be released on 9th February. The x.y.0 releases are followed by monthly updates, which bring bugfixes and new translations.
I’ve done a clean build of KDE 4.4 trunk last night, and I must say I’m quite impressed. There’s a good amount of polish added, everything feels smoother, faster and a couple of really nice features have been added (Blogilo, the program I’m using to write this article, for one). I’ve also test-driven the new netbook-shell in KDE 4.4, and am really happy with it so far. I think, even with the huge amount of changes that went in, KDE 4.4.0 will be a very nice release already, followed up by the monthly bugfix and translation updates of course to provide fixes that arise post 4.4.0. The translation cycle of KDE (there are more than 50 languages available for KDE 4.4), differs a bit from the release cycle. Translators cannot sensibly work off of a constantly changing base. That’s why the feature freeze goes along with a string freeze. This way our localisation teams get the chance to produce a well translated release — something that might not matter a lot to many developers who run bleeding edge english UIs that haven’t even had a chance to get translated. The string freeze makes sure that no new translations are added. Starting with the string freeze, translators are constantly updating the translations for the test releases and then from the 4.4 branch, this way, our x.y.1+ releases are also ever more complete in other languages. In the end, he 4.4.2+ releases is what many people will actually be running for a while, so it’s important we provide a series of updates for them.
So much for a "quick "explanation of how the release process works. In the first paragraph, I told that KDE SC 4.4 is now branched off from trunk. This means that we now start to maintain the KDE SC 4.4 series in a separate directory in KDE’s SVN repository. It also means that if you have an SVN checkout pointing to trunk, you will now get what is to become KDE 4.5 this summer. Anything you commit to trunk from now on will not automatically appear in KDE 4.4.0 and its subsequent releases. That in turn means that through the normal distribution route, your particular patch will not end up on an end-user’s machine before somewhen in fall 2010.
There’s two ways to get those fixes that you’re making faster to the user:
- svn switch to the 4.4 branch. This is actually what you should do (in the ideal world of the release team’s people, anyway). It would be good to have as many people as possible working with the 4.4 branch, at least until we tag 4.4.1. This makes it easy to fix the first wave of bugs we’re getting in after the release of 4.4.0. It’s basically the issues people find who don’t run betas (but are willing to install additional packages by hand to get a newer KDE)
- svnbackport fixes you make. If you are working on some code and are fixing something, consider backporting this to the 4.4 branch (in case you’re using trunk, or another work branch). In kdesdk/scripts, you can find the excellent svnbackport script, which makes it really easy to commit a certain patch also to a branch. It can be as easy as one command, and your users might get a fix 6 months earlier.
While trunk is unfrozen (thawed?), the 4.4 branch of course stays frozen. In there, you shouldn’t commit new strings that would need translation, also new features should only be added to trunk.
As Aaron mentions in his retrospective article, the release team is well in place. I have to agree there. My experience as the "dude who does the announcements" is that the collaboration is really good and natural. We manage to keep the amount of policy sane (believe me, we do!), and we do actually succeed in getting good and stable releases out the door. We’ve hardly slipped our 6 months cycle since the release of KDE 4.0, 2 years ago. And we make our users (new and potential) happy with regular releases, and then actually care about them and supplying monthly updates. The work within the team is also pretty relaxed. For all the work that needs to be done, we have responsible and reliable people that "do the actual thing", we keep short communication lines. At the same time, the decision-making processes feel very natural. KDE does not have a benevolent dictator other big projects (the Linux kernel as a popular one), instead decision-making is done by "those who do the work", taking input from others. Decisions are taken by consensus. This might lead to deadlocks in some cases (strong opinions on either side), but it appears to work really well for KDE development. This takes a bit of discipline from everybody, but I think it yields great results.
Lastly, Dirk (one of "those who do the work") tagged KDE SC RC1 tonight. Tagging means creating a copy of the KDE SC in KDE’s SVN repository, which is then smoke-tested and tarred up as release (and sometimes amended with a last minute critical fix). The tarballs are then uploaded to the FTP master, which distributes the source code packages to the local mirrors, we usually give the syncing 4 – 6 hours, and then announce the release on kde.org, the Dot and to the announcement mailing list. Normally, we’ve put about one week between tagging and actual release. This gives us some time to test the packages (does everything work? does it compile with all likely combinations of dependencies and platforms? and so on). Within this week, the packages from various distros get the packages already, so that they can provide zero-hour packages to their users. (Ever read a release announcement, drooled, and immediately wanted to install it? — This is why zero-day packages are important!) For the test releases, we felt that it’s more important to get the test sources out to the users as quickly as possible, since the version people test with should be as close to what developers are working on (trunk) to make fixing bugs and confirming something’s fixed easier. So RC1 might be out as soon as tomorrow, as it looks quite solid up until now. It means that there might not be zero day packages for those test releases, but it also means that nobody needs to hold back fine RC1 packages until the release team peeps give their blessing.
Thanks for reading all of it, I hope it was entertaining, interesting or enlightening, and that it gives a better idea about some of the inner workings of KDE. My next blog entry will contain a screenshot. I promise. :-)
December 17th, 2009
Two office moves for one
I went to Berlin last week to spend a couple of days with my colleagues at the new KDAB office. The new location is in Kreuzberg, just like the old one, but a bit closer to the city centre. It’s very spacy (about 3 times the size of our previous office near Oranienstrasse), so of course there’s plenty of space to host the foosball table. There are also new training rooms, including a meeting room. While not everything is fully equipped yet, it looks very neat and shiny. The perfect environment for a few days of intensive training courses (with good food and other distractions nearby). It’s also quite cool to have the training facilities right next to our office, so we can always call in a specialist for very detailed questions. The Qt Experts at your fingertips, so to say :)
If you’re interested in those trainings as well, some of my colleagues will be present at Camp KDE, to be held next month in San Diego, California. There will be more general Qt trainings (I followed on given by Till last year, and it’s a really excellent opportunity to get some hands-on experience with topics that would take you weeks to cover on your own because of their complexity. I read that we’ll also do a more specialized training course for Qt in embedded scenarios, surely interesting if you’re into “beyond the desktop” kind of topics. KDAB has been working with this kind of stuff for years, and the training courses are fun and interesting to attend, make sure you don’t miss out! I myself won’t be present, since I’m trying to make my desk-time/travel-time ratio a bit more favourable lately (with mixed success, but I’m trying!).
One interesting details was that after arriving in Berlin, when I was trying to find the right door to our (KDAB’s) new office, I noted a sign for Apliki sign close to the KDAB office. Apliki is the company who is working on icon testing, with their most recent icon test the kmail and kontact icons. So I sent Björn an email, and he came over after work for a bit of chat, a beer and a foosball match. He also showed us the backend for the icon testing web application Apliki has developed, which was really interesting since it provides a way to “measure” usability aspects. Unfortunately, usability is often mistaken as an argument to push your own opinion on a UI, why you like it or why you don’t. These tests provide a good way to quantify the recognizability of icons, and thus allow for a less biased view on how well an icon represents a certain action (or status, object, whatever). The backend looked very slick, and allows for more complex correlation of data. Meeting Björn was of course pure coincidence, but just shows how nice and Free software friendly a city Berlin is.
Working with colleagues was one part of the purpose of my trip. As some of you might know, I’ve been serving in the last years on the Board of Directors of the KDE e.V., the foundation to support KDE. We have recently moved our office from Frankfurt, where we started out a couple of years ago to Berlin, which was more practical with Claudia, our business manager living there, and of course with Berlin being the Free software capital in Germany. We’re sharing the Berlin office with our friends from the Free Software Foundation Europe, which is also very nice since there’s a lot of experience, resources and contacts to share, and our goals largely align — while their implementation doesn’t. In short, nice neighbours of which I got to meet some more last Saturday. The party was really nice, about half of the people had FSFE background, the other half KDE backgrounds with a lot of overlap. I’m happy that we found such a nice place with nice people in Berlin’s city centre (the office is in Linienstrasse, about 150m from U-Bahn Oranienstrasse, which is pretty much spot-on city-centre.
On Friday night, Sebastian Sauer (or dipesh, the guy responsible for Kross and its extensive scripting capabilities in KDE) went to Maelcum’s (that’s the guy who implemented proper SSL support in KDE 4) house warming party. After that, we went back to Kreuzberg to hang out a bit at Breipott (note the creative use ot the TLD :)), a bar with live DJ’ing and lots of Free music. You can just bring your USB stick there and copy music you’ve found — completely legal and encouraged. A really nice Free culture showcase.
Logistically, it all worked out pretty well. I had some productive days at the KDAB office (with also some less productive parts after work — true to our mantra of “work hard, play hard”), and could combine it with some KDE business. On the way back from Berlin on Sunday, I visited my mother and met with other family members I don’t see that often before collapsing at home early that night. Those days rocked, but were exhausting nevertheless.
December 4th, 2009
Konstipation
It’s out. Yes, finally. This release has been a bit of a bumpy ride. First thing was that we decided to do the release two days later, because on Tuesday (the date we’d initially planned), we already had KDE 4.3.4 scheduled. Then, yesterday, Dirk, our package-it hero had to struggle with some build problems in various modules.
Still, this is not a perfect beta. When trying 4.4 Beta1, you might find yourself without compositing effects. This problem has crept up in the last two weeks, and we’ve been only able to fix it this morning, too late for the beta. It turned out to be a problem of stricter capability checking, along with a change of the driver version string reported by mesa. Dirk said, he’ll roll another set of source tarballs next week, so you’ll get your compositing effects back. In the meantime, please focus your testing on other problems.
Allen was concerned about a bug that prevents KOrganizer from starting. We though about disabling KDE PIM for this beta, but in the end left it all in since we do want applications tested, buggy or not.
As you see, we’ve clearly shifted focus from get-your-features-in-mode to bugfix-mode. I’ve had a quick look at the statistics. In the past six months, we’ve closed about 18000 bugs in KDE’s bugzilla. Since the release of KDE 4.3.0, we’ve been able to close about 12400 issue reports. Over the last 7 days, we’ve closed about 900 bugreports. I think we should aim at 20000 closed bugreports until the release of 4.4.0 in February.
A “closed” bug means that a bug is either fixed, a duplicate of another bug that has been fixed, or that the bug cannot be fixed in KDE itself. This is the case for upstream (and sometimes also downstream) problems that really need a fix elsewhere. Some bugreports will also be marked “invalid” or “wontfix”, in which case the bug is actually not a bug (that happens :)). In any case, it means that we’ve triaged the bug and looked into it. Bugzilla is one of the important ways to feed back information to the KDE developers.
Of course you can help with the bug-hunting. Collecting data from a large variety of people, systems and usage scenarios is important to find corner-cases developers weren’t able to test or just didn’t think of. Please report those issues you run into! When doing so, for developers it saves a lot of work if you have a good look if your bug is already reported, don’t assume it is, but also don’t assume it isn’t.
When you’ve reported a bug, it’s helpful when you’re responsive to emails and check on your bugreport once in a while. We might need further information, there are often workarounds, and in some cases, it’s helpful for fixing a bug if we have short feedback cycles with someone who’s actually experiencing an issue to check further, or maybe ask to run a patch. The better your bugreport is, the easier it is for us to fix it.
Of course, KDE being Free Software, you can have a go at fixing some problem yourself, the source code is readily available, and if you know a bit about programming, issues are often easy to find and fix. In general, I find the KDE source code to be easily readable and understandable. In doubt, you can always ask another developer for directions, on IRC or one of the -devel mailinglist.
So, what’s so significant about KDE Software Compilation 4.4? Well, it’s a huge package of software, dozens of applications, a kick-ass development platform and an organic and usable desktop shell. One of the more noticeable changes that really cover all applications are probably the subtle transition effects that have been added to the Oxygen widget style and window decorations.
Another doublepluscool feature is the tabbed window manager. This new feature makes it possible to group arbitrary windows using tabs. You can now simply drag a window with the mouse wheel pressed onto another window and they’ll be grouped in tabs. The tabs are part of the window decoration, detaching windows works in the same way. Another very nice feature is the edge snapping. Dragging a window against the left or right border will put it on one the of side of the screen, exactly at half of the width. Dragging against the top edge will maximize a window. This way, you can easily tile (and group, with window tabbing) arbitrary windows.
I’ve stumbled across a nice video of some of the visual changes in KDE Plasma 4.4, you can find it here:
November 28th, 2009
Battery Applet – The Sequel
There have been quite some comments to my previous blog, among them some good points how to further improve the clarity of the battery applet’s info and control panel. I thought the best way to address this is with a patch, and a bit of explanation of those changes. So here’s the dialogue after a bit of further hacking on it:
Let’s look at the latest changes:
- Bigger informational text, bold labels — Checking the charging state is the primary usecase of the panel, adding a bit of visual weight to the top section makes it easier to spot the information
- Separator between info section and controls removed — As some people pointed out, the separator between the info and the control section resembles the brightness slider a bit too closely, and distracts visually
- Configure button moved in line with the profile combobox — This is actually a very good point. It makes sense to put the configure button next to the profile combobox. The button actually leads to the profile configuration settings. It also makes it possible to …
- Move Sleep and Hibernate buttons in line — Now we have two instead of three buttons in the lower section of the controls, we can actually put them in line and get rid of the large hole in the lower part of the dialog.
- Aligned labels and controls horizontally — This last one is a label alignment bug in my code notmart quickly fixed after seeing the screenshot. Thanks dude! :)
I think that it works indeed better visually with those changes. The separation between info section and controls are better, the alignment of the widget overall is clearer, and as you can see, we’ve also saved quite some horizontal space. While it’s certainly not perfect yet, I think it’s a really nice improvement. Thanks to those who came up with the suggestions. I’ve just committed the patches to trunk, so they’ll be in KDE SC 4.4 beta next week.
On a sidenote, I had to order a new battery today for my beloved Thinkpad T60. The battery I’m using is, as you can see totally worn out. If you, dear lazyweb have suggestions how I can revive my (by now three) worn out accus, I’d be most grateful. I guess the constant plugging and unplugging of the accu and power cable isn’t the healthiest diet for this kind of hardware. Ow sacrifices … ;-)
Update: I’ve removed the percentage from the battery picture in the dialog, since it’s redundant (already displayed next to the “Battery:” label). Also, the dialog now reacts to font size changes on the fly.
November 27th, 2009
Battery Improvements in KDE Plasma 4.4
The battery applet in KDE Plasma 4.4 has gotten some nice improvements. First of all, I wasn’t really happy with the layout of its popup dialog. It looked messy and didn’t scale well with bigger fonts. During Tokamak3 in September, I started improving this. To make it look calmer, I reduced the amount of edges widgets are aligned to. The previous version used nested layouts, which lead to widgets not properly aligned with each other. This creates a rather messy look. For 4.4, I’ve reworked the layout and reduced everything to only one layout and attached the battery in the popup off-layout in the top-right corner. I thought about using an AnchorLayout for this, but a simple setGeometry() to position the battery top-right would work as well, so I went for KISS. I also replaced the text on the "Configure Power Management" button with a tooltip, reducing visual clutter but keeping this handy in-context shortcut to easily get at the more advanced power managment settings.
The battery popup now resembles a FormLayout more closely, which should make it more consistent with how other dialogs in KDE are designed, so that’s a bonus in consistency. The two screenshots show the old and the new version of the applet side-by-side.
One wish came up more than once over the past months. Some (very vocal) users would like to see the battery showing the remaining time when it’s running on battery. Normally, the applet would show the charge percentage, which is a rather abstract number. (How long is 37%?) Now unfortunately, there’s no way to give an accurate estimation oft the time that’s left, since it largely depends on the usage patterns. You check the battery, it says "10 minutes left", then you start some app that exercises your CPU and disk and suddenly the machine goes into suspend after 3 minutes. Quite possible, and the usage scenarios and differences in modern portable hardware are such that there’s really no way to accurately predict the remaining battery lifetime. In the Plasma team, we decided that we rather not show the user unreliable information, since there’s only a very small group that understands that this number is almost black magic, and often simply wrongly reported by HAL. There’s well over 200 emails on that subject, mainly on the Plasma mailinglist and everytime this topic comes up we hear how much KDE must suck if this tiny little feature isn’t available. We’ve made this feature available in KDE 4.3, as a hidden config option (meaning that you cannot enable it using the configuration UI, but it’s there if you enable it in the configuration file. I had tentatively disabled this code during the larger part of the 4.4 development cycle to see if I’d get away with ditching it, and it didn’t quite fit in with the new layouting for the popup.
Lately, the same discussion came up again, hopefully for the last time, since I submitted a patch yesterday night that brings the remaining time back (still as hidden config option, and that’s about as far as we will go). No, there won’t be a checkbox since I don’t want to confront users with information that’s most likely bogus and highly depends on what you’re doing at this very moment. As the option needs a power user to understand what this info really means (i.e. an estimation that’s completely off or not, depending on what your BIOS or ACPI subsystem reports), I think we can reasonable expect that adding a line to a config file is easy enough for those who really, really, really want it.
So, for reference, here’s how you get the remaining time display in the battery applet.
- Install KDE Plasma 4.4, at least trunk from today
- kquitapp plasma-desktop (to stop your plasma shell, as long as it’s running, it can’t pick up config changes, if you stop it after you changed the config file, it will happily overwrite your hand-made changes on quit)
- Open your plasma-desktop config file, (mine is ~/.kde4/share/config/plasma-desktop-appletsrc, YMMV)
- Locate the section for the battery applet, in the below example, you’ll find the plugin=battery line, choose the section that adds [Configuration] to the identifier. This section might not exist if you’re using default settings, in that case, it’s easiest to check the “show charge information” checkbox in the battery’s config (you might need to restart plasma-desktop for that, don’t kill it afterwards but use kquitapp). Then locate the showBatteryString= line and add another line in the same section:
showRemainingTime=true
- Save the edited config file, restart plasma-desktop
[Containments][3][Applets][7][Configuration][Applets][30] geometry=140,2.5,30,24 immutability=1 plugin=battery zvalue=0 [Containments][3][Applets][7][Configuration][Applets][30][Configuration] Share=false showBatteryString=false showRemainingTime=true
The remaining time will now be shown if it’s non-zero (obviously bogus since the machine would be off then) and the battery is discharging. If in doubt, use “plasmaengineexplorer –engine powermanagement” to check wether Solid reports the remaining time at all, and that it’s non-zero. The remaining time could also be shown while charging, but this apparently isn’t supported by my setup, so I can’t test it.
Also during Tokamak3, Dario fixed a bug that would switch the display’s brightness back to 100% after it was dimmed because the machine had been idle. So if you’d set it to 50%, and it would then dim after some minutes of idle time, you’d move the mouse and it pops back to 100%, while it should go back to 50%. That’s fixed as well, and the patch has also been backported to KDE 4.3. You probably are already running with this fix.
Update: I’ve just committed a couple of changes to the battery applet and explained them in a follow-up blog
November 20th, 2009
I’m a *real* developer …
… not just a marketing guy. :-) During the Qt Developer Days in Munich, I took the Qt certification exam (actually as one of the first people to take it). It was my birthday, so they let me pass:
Also, right now I’m in Reykjavik, Iceland for the KDAB company meeting and 10 year anniversary. Preliminary conclusions: Watch out for roastbeef, it tastes like whale, riding on a horse feels like riding a square-wheeled bicycle (but slightly more scary) and having infinite amounts of energy under your rearside makes for interesting and relaxing uses and given a large-ish island with tectonic and seismic activity, you’ll find the capital at the most likely spot for an earthquake.
November 12th, 2009
openSuse 11.2 rocks
Suse Linux 7.2 was the first Linux version I’ve installed myself and ran. Around 2001, I worked as webmaster at the Nijmegen School of Management, where I also studied back then. Fred Melssen, who was my colleague back then asked me to build a new webserver and sent me to the local bookstore to get a boxed version of Suse, which came, and still comes with a nicely printed manual. Fred told me to familiarize myself with the system so we could move parts of the infrastructure of the faculty’s quickly growing web infrastructure to Linux. Back then, I also started using Linux and KDE as my desktop, first using an X Server running on Windows 2000 and using the remote desktop from that machine. So SUSE Linux (or was it still called S.U.S.E?) was my first free OS.
I installed openSuse 11.2 on a new computer I picked up from a shop earlier. It’s a small form factor desktop, with a 1.6Ghz Atom CPU, an Intel 945 graphics chip, 2GB of RAM and a 160GB hard disk. Nothing fancy, but good enough for web browsing, emails, and “casual computing”. The installation went smooth, I could even install it from a USB stick, which is nice since it seems to be faster and produces less useless coasters. After booting, I’m really impressed and pleased with the Operating System. It simply doesn’t get in the way, everything is nicely integrated, even Firefox. It looks all very well polished, from technicalities like suspend/resume working out of the box, compositing effects enabled without having to do anything, and even sound just working (apparently pulseaudio has been removed from the installation) to visual aspects. I also very much like the looks, it looks very much like openSuse, but really slick. The theme it uses is based on Nuno Pinheiro’s Air which is the default for KDE 4.3. As part of a programme to streamline branding between up- and downstream (in this case KDE and openSuse, other distros are also involved), Nuno has been working with the openSuse guys to provide a branded theme for openSuse. The result is simply astonishing, and it the result of years of hard work from the Oxygen theme all across visual and aesthetic aspects of the OS (pun intended). It’s really nice to see icons, widget theme, window decoration, wallpapers, desktop widget theme and so on all matching so nicely, enhanced by subtle translucency effects and animations. It’s very beautiful and usable.
Congratulations to the openSuse community to a solid and beautiful release!
October 30th, 2009
Dropping $stuff onto Plasma
Earlier this year, while working on Lion Mail I wanted to be able to drag and drop references to items stored in Akonadi, I ran into some limitations we had in Plasma — in KDE 4.3, it is basically only possible to drop local files onto Plasma, with some exceptions. Think of dragging a photo from your file or image browser onto Plasma, and it offers to create a picture frame plasmoid on the desktop (or netbook, or whatever Plasma shell you use). or The underlying problem is the mimedata dropped either contains a URL or mimedata. The second case is clear, get the mimetype, find applets that can deal with it, add such an applet to the desktop and pass it the mimedata as arguments. Applets can specify, as parts of their metadata (actually an entry in their .desktop file) which mimetypes they support. For remote URLs, it’s not quite simple. It’s generally not possible to safely derive the mimetype of the data a link points to from its URL. The mimetype needs to be retrieved from the remote object (in most case, this doesn’t involve downloading the whole file, luckily, but just asking for the mimetype). As it’s likely a network operation, it can potentially take forever. We need to make sure we don’t freeze Plasma while waiting for the mimetype, so it has to be asynchronous. What we’re doing now when a URL is dropped, we start a KIO Job to retrieve the remote file’s mimetype, as long as the job’s running, we show a menu with a spinner, and repopulate the menu with suitable applets once the mimetype is in. The job retrieving the mimetype is then put on hold, and marked ready for reuse. This trick speeds up loading of the content from the applet, and the connection doesn’t have to be renegotiated. This mechanism works well now, I actually got it to work during the hacking sessions at GCDS, and merged it a few weeks later into KDE trunk/ to be part of KDE 4.4. Aaron has done a screencast showing this mechanism for wallpapers, it’s pretty neat.
(You can download an ogg version on blip.tv as well.)
The problem with this mechanism is that it’s not flexible enough for a couple of things I’d like to do, especially not for Akonadi, and also not for applets we want to create based on a specific web service, or anything else that you can safely derive from the URL. I’ve been thinking about a good solution for this for some time, but didn’t have high hopes to actually make it work in time for KDE 4.4, with the feature freeze looming in only a couple of weeks. On Sunday, I had told Steve (he asked for Akonadi/Plasma interaction, see below) that KJots notes (which are stored in Akonadi) should be drag’n'droppable between Kontact and Plasma (and possibly other applications), and that the way to go would be to pass around typed references to akonadi items by URL (basically akonadi: as protocol, the item’s unique id and its type wrapped into a URL). A lame suggestion in fact, since I knew it wouldn’t work. Then I figured if Plasma::Applet could just tell me which applets are suitable for a given URL (a mechanism similar to the mimetype-based finding of applets), we’d be peachy. Hacked up a patch for that and got it working just before I went to bed, had some good feedback the next day. So I went to clean up and optimise the patch a bit, had it review-boarded overnight and committed it this morning. Applets can now provide matching patterns for URLs. You put a wildcard (or a list of wildcards, useful if you want to cover some subdomains, but not others), in the .desktop file of the applet like this:
[X-Plasma-DropUrlPatterns]=akonadi:*
You can use the usual wildcard syntax, and put in multiple patterns (separate them with a “,”). This makes your applet automatically appear in the popup you get when you drop something onto Plasma. The patch weighed in at 35 new lines of code, quoting Aaron “impressive what’s possible with so little code”.
On an semi-related note, Lion Mail is getting better with every Qt release. Painting and clipping problems I had in scrolling with graphicswidgets seem to be gone completely when using Qt 4.6 snaps. Some automatic relayouting issues remain. Lion Mail’s Email QGraphicsWidget (the canvas-based equivalent to a “normal” QWidget) used dynamic relayouting pretty heavily, as it shows different parts of an email based on the screen space available for the applet. I’ll have to revisit some of this, it might be interesting to take the concepts and implement them using QML & declarative UI tech for that, and also making use of the Pure Awesomeness of steveire’s Elite EntityTreeModel for Akonadi. I’ll let him figure out how this works best for KJots first, though. :)
