jkt's blog


Entries from September 2008.

KPhotoAlbum Development Sprint: Part 1

As you might already know from the news item at the KPA website, I'm currently sitting behind a table in a wonderful country of Denmark. I'm not sitting there alone, though, because we're having a small KPhotoAlbum development sprint right now. Jesper, the main author, was so kind to invite us to his home, the KDE e.V. paid the flight tickets, so all we have to pay is just the barrels of beer and the T-shirts. And that's an investment a typical developer makes with pleasure :).

So far we have made just 17 commits, but there's a lot of talk going here (hi Tuomas :p). For exmaple, the SQL backend is getting closer and closer to being completely ready, the support for multiple cores is shaping up (and you won't see that annoying flickering anymore) and we even have a cute, transparent infobox which looks really sexy.

Right now, I'm working on a reworked EXIF/IPTC/XMP import/export thingy, which would essentially allow you to customize how KPhotoAlbum imports the metadata from the images, and also to store these data back to the files for increased interoperability and stuff like that. So I'll be finally able to share all the captions and tags with a friend of mine who's using XnView. This feature was already present in the 3.1.0 version, but the GUI for it was, well, not really intuitive. I'm converting it to Kross, the KDE scripting environment.

As I brought a GPS device some time ago, one can also expect some efforts for integration with Marble. There's also a whiteboard full of interesting ideas which I won't mention here.

Tags: gentoo, kde.
KPhotoAlbum Development Sprint: Part Two

Image Stacking

As Henner writes, we've managed to add a new feature that some users were requesting for quite a long time -- now there's that thingy for marking several images as "belonging together".

Imagine you've taken a group photo of bunch of your friends at a pub. You weren't exactly sober, so perhaps some of these are shaky, out-of-focus or otherwise imperfect. You weren't drunk as a lord, though, so there's one of them which is pretty good. Now you don't want to erase all the other pictures, but you don't want to see them by default, either. So what you do now is to make an Image Stack of all of them and select which are bad and which one is the best one. This feature might be useful for various variants of images decoded from one RAW file or for images stitched to one big panorama as well.

It's far from complete yet (the GUI part still sucks and you can't select your order of preference, either), but it's a good start and it got done pretty fast.

Lets look at an example stack with a picture of Gunvald (Jesper's dog) on the beach. The default view in the thumbnail view shows only the first picture:
collapsed stack view … expanding to
expanded stack view

Please read Henner's post as well and let us know what you think about this feature.


Shortly after my last post, I got a bunch of mails from our users. It's great to hear that people are interested in our work, so many thanks to all the readers! Please keep the comments going. Anyway, the most frequent question was interoperability with Digikam.

At first, I'd like to mention that I'm on a KPhotoAlbum Development Sprint. Nobody of us over here is hacking on Digikam. It surely is a great piece of software, but we don't use it ourselves. That's why I have to disappoint one reader of this blog -- nope, I can't blog about new features in Digikam, sorry. But be sure to check out the KDE Planet form time to time, their development team is blogging every now and then.

Now the interoperability thingy -- we have a nice file describing what the problems are. Looking at the document, I'm afraid that both applications are using quite different approach to tagging -- in Digikam, tags are (I haven't check the Digikam sources, nor am I using it, so this might be actually wrong) apparently in a flat namespace, while in KPhotoAlbum, we use a hierarchy (a tree) of tags for features like "pictures of Anna should be recognized as pictures containing anyone of my friends as well". This is certainly not a showstopper, but quite an important issue nonetheless.

However, please don't get disappointed too early. The question is -- why should we somehow prefer interoperability with Digikam over, say, XnView? There's a lot of users out there who are using different applications on different operating systems, and we'd like to do our best to be interoperable with all of them. At the same time, we certainly aren't willing to be held back by lack of features in other applications. Therefore, we won't write any feature like "copy my database to the Digikam format", nor do we expect Digikam to be able to import our stuff. (There's nothing holding you back in writing your own converter, though -- our format is pretty simple to deal with.) What we will do, however, is adding a feature for metadata import and export. We'll use standardized stuff like Exif, IPTC and XMP, so that it should be easy for KPhotoAlbum users to provide their friends with images with embedded tags (and the other way round, of course).

KDE4, SQL,...

Another question was a state of the KDE4 port and the SQL support. I'll leave that for another blogpost, as this one got pretty long already :).

Tags: gentoo, kde.
State of KDE 4.1 in Gentoo

Dear lazyweb, it's been some time since KDE 4.1 was tagged. Gentoo, which used to be one of the most bleeding-edge distribution, has apparently failed to deliver this highly expected product to its mainstream users. We already have even a KDE developer complaining about what a miserable job we did. Well, I'm not going to deny the fact that the lack of KDE 4.1 in Portage probably doesn't make users happy, but let's see what the reasons are. Perhaps I can even persuade the P. T. reader that the statement "nothing happened in the Gentoo land" is false :).

I should probably add a disclaimer that even though I'm a Gentoo developer and have a KDE SVN account as well, I don't maintain KDE packages in Gentoo, nor do I hack on core KDE code. My KDE role is limited to working on KPhotoAlbum.

The Package Manager

First of all, one has to admit that the package manager in Gentoo has had some long-standing issues which weren't exactly easy to solve. Due to the extremely wide set of options a user might have when installing a package (I'm talking USE flags here), testing all of these options is not a trivial task. Moreover, the possibility to depend on a package being built with some specific USE flag wasn't available until recently etc.

Preparing a package for a source-based distribution is not as easy as rolling out a binary package.

I won't go into much detail as it'd be probably pretty boring for an average reader, but a quick summary is that the KDE team went ahead and instead of keeping using the same hacks that were employed in kde-3 ebuilds, they drafted a new revision of EAPI, the standard that describes functions available to and the interaction among the ebuilds, the Gentoo packages (think about a .spec file for RPM). From user's point of view, and especially in the short term, there are no immediate benefits, and the big downside is that this whole process takes a lot of time. From a technical POV, though, this is the right decision, no doubts about it.

The way of creating a new EAPI is not that easy, though. As we're talking about a standard which is going to affect Gentoo as a whole, a lot of people want to make sure there are no obvious issues with the specification. One of the results is that there's usually some talk going on on the various mailing lists, one has to work closely with package manager authors to make sure that all the cool ideas are actually implementable etc. And note that one really can't use the new EAPI in the main Portage tree until it's approved. (The good thing is that it apparently got approved during the last Council meeting, which happened such a short time ago that we don't have a summary from it yet :) )

The Manpower

Yep, there were personal issues involved as well. Three members of the KDE team left Gentoo, others got pretty busy with Real Life™ and other projects of their own. While we are already seeing other people stepping up and helping the KDE team, the lack of manpower is certainly a problem. Gentoo, being a non-profit distribution and what not, can't afford having a paid developer working on KDE packages. I'm sure there are other (even source-based) distributions who aren't backed up by any company, either, but you should take this into consideration before you declare Gentoo as "dying".

The Code

So, if you've managed to read the whole mess up to this point, I guess you deserve a reward of some kind. So, what about a KDE 4.1 package? What? You thought that it is not available? Oh sure it is! It isn't in the main tree (remember, you can't use unapproved EAPI in the official tree), but available through an overlay and adding it is not really such a big problem. Please go on, read the instructions and enjoy KDE 4.1 on Gentoo!

Tags: gentoo, kde.