KDE Commit Digest 51: strigi, digikam, kopete and kjs

Commit Digest 51 has been released. Usually it contains a huge amount of interesting information – well, at least for the KDE interested people.

As usual the introduction of the Issue 51 summarizes some important information. For example the Oxygen project finished the transition of their icon names to the freedesktop.org icon naming spec. This means that

default KDE iconset of KDE 4 [is] now largely cross-desktop compliant

There are some other topics I would like to pick up:

strigi

There has been lots of strigi related work lately. Most notable currently is the work done around the extraction of metadata from files: in KDE 3 this was done by KMetaFileInfo, in KDE 4 this will be done by stream analyzers. So to get ready for KDE 4 all old KFilePlugins have to be ported to the news subsystem. A howto to do that can be found at a techbase page. The state of the current porting efforts can be seen here.
And is it worth it? According to superstoned it definitely is: in a mass test with xml files the old plugin needed some 2 minutes but the new analyzer needed only 13 seconds. To be fair this was mainly due to problems the old plugin had with figuring out the metadata type.
Jos van den Oeve, the main developer of strigi, tested the png plugin and found that this is much faster as well, although he didn’t include any numbers.

I’m really looking forward to see the use of strigi in day to day tasks.

digikam

One of the apps I used regularly – and which I would use more often if I would have a real digital camera – has also very active developers. This week the famous dikigam image plugins were moved back into digikam core: the reason is that the digikam image plugins are always and only released together with a new digikam version. And the plugins were never used by any other applications.
Also, the navigation inside of a larger image became easier: now digikam features a small total-view tool like for example google maps:

I like that one!

Speaking about digikam, I wonder what the project plans about a KDE 4 port.

Other details

Another detail worth mentioning is the re-merge of a kjs-experimental branch back to the original branch. The idea of the experimental branch was afaik to test some things outside of the usual kjs development. With this re-merge we might see better JavaScipt support in KDE in the future.

On the other hand, kopete just got a new test branch for testing new ideas around the kopete GUI:

revert current model work in favor of a more defined split between the libkopete stuff and how that stuff is represented in the GUI.

Ok, honestly for me the kopete GUI isn’t that much important, I’m more interested in the p2p-jabber stuff (jingle, file transfer, video, etc.). But still, nice that there are experiments, maybe they lead to new cool GUIs.