Trueg's Nepomuk Blog

It took me one and a half day and Jos will not be happy about it. That is because I have to start this blog entry with apologizing to him:

"Jos, I am sorry, you will probably not like what I am about to present here. But this makes it so much easier for me and all the KDE people. And strigidaemon simply does not provide the needed features, which I can understand since you are doing this in your spare time. But I cannot wait any longer and in the end really want to reuse all the nice KDE features instead of reimplementing it all just to keep away from QT/KDE dependencies. I hope you understand."

Now that the tension is built up. What did this guy do? Well, essentially I reimplemented strigidaemon as a KDE Nepomuk service. Why would I do that? Why would I reimplement an existing working application? Simple. For the following reasons:

• The parts that I copied from strigidaemon are rather small since all the work is done in the streamanalyser library. So "reimplementing" is maybe a bit overstating it.
• Managing strigidaemon is not that easy as there is no proper method to suspend/resume indexing. You will see below why that is important.
• strigidaemon does not inform about what it is doing. Thus, having an information GUI is impossible.
• The new service is of course a Nepomuk service and as such, can make use of all our nice Qt/KDE features:
  • It uses KDirWatch to watch all indexed directories for change. In comparision the inotify/fam support in strigi was never completed and also meant to maintain 2 dirwatch implementation: one in KDE and one in Strigi.
  • It uses Solid to get notified about power state changes - indexing is suspended when your laptop is running on batteries.
  • It regularly checks the available space on the home partition and suspends indexing if the space runs low (also very simple via KDiskFreeSpace. Using Qt/KDE is so damn great! You really can focus on the important stuff!)
  • It shows info messages about its status via KPassivePopup. Very KDEish and smoothly integrated with the desktop.
  • It shows a GUI to inform the user that the initial indexing can take a while and gives the possibility to configure/disable/suspend/resume strigi (see below for a screenshot of the widget for which I'd like your input.)

For me these are more than enough reasons to commit the new service in the next days. It will solve the Strigi situation for many of our users that always disable/kill strigi because they don't get any information about it from KDE.

As I said above I wanted your input for the GUI. The idea was to make it non-intrusive but have it staying in a corner of the desktop until indexing is done or the user closes it. Here it is in all its uglyness:

Please help me to make this widget useful.

Jos, I hope you can understand why I did it. It was rather simple and gives us all the features we need. Without reimplementing all the nice things KDE has to offer.

No, I did not forget about the virtual folders, but I also did not implement subfolders or a graphical query editor. Shame on me, I know. I thought it was more important to focus on stability and a clean API first. And that is what I did.

But before that let my point you to the blog of my Google Summer of Code student Daniel Winter who uses Nepomuk to improve Amarok playlists. Cool stuff.

Back to virtual folders: Last time we saw that we could list query results wherever KIO was used. This time, I will only give a short update for the users and a way more interesting one for the developers:

The User Perspective

I won't give you much to read but provide a little screencast (Update: now better quality!) showing how virtual folders are now updated automatically:

Normally this is where the video should be embedded now but apparently it gets filtered out, so here is the link again: Nepomuk Virtual Folder Screencast

If you are a user and do not care about how stuff works you can stop reading here.

The Developer Perspective

IMHO what we just saw is pretty nice (but there are issues as always: if you know KIO, you know that unused slaves are terminated. The same is true for the virtual folder io slave. Once it is terminated we loose its internal state and, thus, the updates. Well, if you have any ideas to solve this.... the only one I could come up with is a hack to force the slave to not be deleted until not needed for updates anymore).

And why is this so interesting for developers? Simple: the virtual folder KIO slave does "only" convert the search results to proper KIO UDSEntries. The actual results are created by the brand new Nepomuk Query Service.

This service has a rather simple DBus interface. You call the query method and get a new DBus object which informs about new results and removed results as well as the finishing of the initial listing. And this is totally generic and not restricted to files.

If you want to try it and support my proposition to get it into kdebase for 4.2: you can find it in playground/base/nepomuk-kde/queryservice. In the subfolder "client" you find the client library. Use that and you don't even have to care about the DBus communication. Simple.

Keep in mind that the query API is still in development and your input and wishes can still easily be adapted.

After more than two weeks of vacation I read up on my email and of course am also sickened by some of the stuff I have to read there. Let me open with a quote:

Here's a real suggestion: give us back our Desktops!

That is just plain sad! But it pretty much covers the topic of the whole Aaron/Plasma unpleasantness. Aaron and the Plasma devs are trying something really innovative here, trying to bring a new level of usability and beauty to our desktop. This is not an easy task but nonetheless they do it and IMHO they succeed. And what do they get for it: bashing and complaint over complaint.

Being a developer myself, I know how frustrating even one mail of the "your-solution-is-crap-do-it-this-way-it-will-be-easy" kind can be. But getting such a load of them over months. Man, and still Aaron continues to work on Plasma.

Even if it was not possible to have the old plain and boring desktop back, we should get over ourselves and give new ideas a chance! The whole KDE4 thing is such a brave endeavor. Introducing so many new things, knowing that KDE will lack features for quite some time, and doing it anyway because the desktop has to evolve somehow... why do so many people always only see the problems and never the opportunities? Or are they like me and shut up about it? Is that our problem: do we only speak up to complain but never to praise?

If that is the case, then here we go: I personally think that KDE 4 is a great step forward. I know that it will take some time to port all KDE 3 features. But all the new ideas, all the chances that were taken, make me proud to be part of it. Thanks and congratulations to all of you who took the chance!

I think I am one of those benefiting directly from the willingness to try new things. After all, the KDE developer community gave me the chance to bring Nepomuk into the KDE 4 mix, even though there are still usability problems around and the real benefits are not yet visible. The only reason I don't get beaten over the head all the time like Aaron, is that Nepomuk is not as visible, not as sexy as Plasma. And for once (after envying Aaron for nearly two years) I am happy that many users fail to understand what Nepomuk is or that I fail to explain and promote it properly.

Aaron, I am sorry, that I did not step up before. I, too, should know better. So today I do.

Addendum: I stopped reading the main thread on kde-devel after half the messages. Even I could not take it anymore. How could the Plasma devs and Aaron?

Really. I just got my awesome KDE metal gear award for my work on K3b and I have to say: work of art. This is so cool and such an honor. I can't find better or more words....

Well, maybe "The Next Level" is overstating it but I improved the query API a lot. Not only can we now properly handle all sorts of literal comparisons but we can also use plain SPARQL queries. The latter allow some nice stuff like "Recent Files".

For anyone interested the "Recent Files" virtual folder is coded using the folloing SPARQL query:

select ?r where { 
    ?r a <http://freedesktop.org/standards/xesam/1.0/core#File> . 
    ?r <http://freedesktop.org/standards/xesam/1.0/core#sourceModified> ?date . 
} ORDER BY DESC(?date) LIMIT 10

A very simple query that just selects the 10 most recent files.

Also nice are the folders listing all files modified today or yesterday. Anyway, time for a little screenshot and for me to code some query creation GUI (and maybe nested virtual folders).

Virtual Folders in KDE

You can tag files, you can annotate them, Strigi indexes your files, I showed how to create new information types and things, but you could not really use it. I suspect you want to find the things again by searching for it. Well, I don't think we should search. We should simply find!

OK, enough of the bragging. Introducing Nepomuk virtual folders.

Step 1 - Predefined Virtual Folders

There are the default predefined folders. An example (and honestly the only I defined so far) is the folder that lists all music files (actually all music files indexed by Strigi. So, yes, Strigi needs to be running for this to work best.)

Step 2 - On-the-fly Virtual Folders

We can also define our virtual folders on the fly by simply using the nepomuksearch:/ protocol in combination with the query (I personally would prefer to hide the protocol in a nice GUI but that is polishing for the future). If we for example want to list all resources related to Nepomuk:

We get files tagged with tag Nepomuk, we get folders that contain the term "Nepomuk" (indexed via Strigi again) and we also get the tags themselves. The latter is most interesting as the tags are Nepomuk resources which do not relate to any file. KIO can list them anyway and even displays the correct type. The display of the correct type which is read from the Nepomuk store was achieved by a very small patch to KFileItem which I hope will be accepted. It basically treats the "application/x-nepomuk-resource" mimetype as a special case very much like "application/x-desktop". But instead of reading the type from the desktop file it is read via Nepomuk::Resource::resourceType. Simple but effective.

Well, off to a better example, a real example. Let's say we wrote down some notes using KWrite and saved them in some folder anywhere in the home directory:

Now instead of clicking through the directory hierarchy in search for the file we simple access it using a Nepomuk virtual folder. Be aware that the word "nepomuk" is part of the text itself while the word "notes" is part of the file name.

As a last little example we reuse the information created in my last blog: my friend Tudor. He can of course also be accessed through a virtual folder:

Again the type information we created ourselves is used in the KIO slave. Well, that is it for today. I am off to work some more on the folders, making the query language more expressive (at some point we will need variables in there!), and maybe creating a virtual folder service. The latter could then be used not only for KIO virtual folders but also in KMail or some other application to list whatever resources one likes.

Now what is that supposed to mean? The "real" Nepomuk? Well, you did not actually think that I would introduce an RDF store into KDE just to save some tags and ratings? No, the "real" motivation goes way beyond that and it is time to hint at it.
Today I committed the PIMOShell to the Nepomuk playground (To the right you see the PIMOShell main window showing all xesam:Music resources).

The PIMOShell is a metadata maintenance and debugging tool which I will now use to give a glimpse of the "big picture".

But first a few words on PIMO: PIMO, the Personal Information Model Ontology, forms the basis for all custom, user-created classes (types) and properties. It defines basic stuff like an Agent or a Location and is intended to be extended by the user in any way he or she likes (more information on PIMO).

Let us dive into an example:

By using the context menu in the upper left class list PIMOShell allows us to create new classes with a nice little dialog. Basic information like a label and an optional icon and description can be added directly. We create a new class "Friend" which is a special kind of Person: a close friend.

Once the class is created it shows up as a new subclass of pimo:Person which in turn is a subclass of pimo:Agent. It can now be used like any other class in the system. That essentially means that we can create instances:

Again we can set basic properties like the label and the image. We create an instance of Tudor, my friend from DERI, Galway. Once we did so, PIMOShell lists Tudor as a new instance of Friend:

Now Tudor has been created as a new RDF resource in the Nepomuk storage. And that means we can query him using the simple Nepomuk query client:

When searching for all resources of type "Friend" we find Tudor. Nice.

But simply creating new classes is not fun enough. To categorize friends we might be interested in what relates us to them. Like a mutual interest. Thus, we create a new property:

As you can see the new property will be for our new class "Friend". And once it is created we can change its value in the lower pane:

The mutual interest that I share with Tudor is complaining about bad food (just for the sake of the example of course).

Again the new information allows us to find Tudor:

I personally think this is quite cool. Of course the PIMOShell is not intended for the end user. But it gives an idea pf the possibilities. A PIM application might categorize according to user created classes with additional fields, saved text documents might be typed, we can organize arbitrary data in a powerful way. All we need is a deeper application integration. And this is where you come in. I hope.