GSoC Wrap-up Part 2

Last time I presented the work Adam Kidder did on Nepomuk virtual folders in the GSoC. Today the story continues with the work by Alessandro Sivieri, my second GSoC student.

Whenever we handle files on the computer we need to bother with folder structures and file names. We need to come up with good naming schemes which allow us to find our files. We need to decide several times a day in which folder a file should go – should it go into folder A or B or should I create a subfolder? In the end there is always a little bit of chaos, even with the most structured minds. Alessandro tried a different approach in his project: save and load documents based on meta data and annotations rather than file and folder names.

This is not an easy task but I dare say that he succeeded. Alessandro created two new dialogs for saving and loading documents (we do not talk about files anymore – way too technical). The saving dialog allows to create arbitrary annotations for the document using the Nepomuk annotation plugin system which also brings in Scribo text analysis features. The loading dialog on the other hand uses a fancy filter system to narrow down the list of documents to open.

Saving Documents

We start by looking at the document saving dialog. Our example is KWord from which we want to save a fancy little text document. (No, it is not a test document, I really wrote this, this is real data, I assure you! … Yeah, OK, I admit it, just random words…) Hitting the save button opens up the new smart save dialog as can be seen in the screenshot below.

Smart Saving of a KWord document

The first thing we notice is that there is no filename and no folder selection. Name and folder are selected by Nepomuk. However, we get to give the document a name (it makes things much easier for us later on) and a description (in a future version applications will be able to prefill these fields with some meaningful defaults). But the interesting part is the meta data. The dialog suggests certain possible annotations which we can approve). Below the recently used annotations we have the possiblity to add any annotation we want through the existing Nepomuk annotation system. Last but not least we can give the document a type. This type does not identify the document on a mime-type level but much more real-life oriented. The idea is that users either define their own types based on pimo:Document or use ontologies that provide them. Typical examples include invoices or letters or project descriptions. This way documents are saved on a much higher abstraction level than with the classical file chooser: instead of a text file we save an invoice.

Once we specified the meta data we want to apply to the new document and hit the save button the smart save dialog generates a folder and file name and saves the document. We do not need to care about the location.

(Hint: there are certainly situations in which we want to use the classic file chooser. That is why the smart save dialog allows to switch over to the old ways by the simple click of a button.)

Loading Documents

But if documents are saved in some random folder which we do not know, how do we find them again? Well, that is the real beauty of the new approach. The idea is that you tell the open dialog what you want to open by specifying some details that you remember.

Let us have a look at the smart open dialog as it opens from within Okular.

We see two main views: on the left hand side we see a list of filters and on the right hand side we see a long list of files/documents. This might look overwhelming in the beginning but wait until we specify the first detail about the document we want to open: we tell the dialog that the document has mime type image/png (Yes, in the future this will look less technical) and the file view changes only showing png images.

These are still way too many to search for the one we need, so we give more detail. We remember that we accessed the document sometime this week:

Again the list of files is changed and now after only choosing two filters we are down to seven documents to choose from. Although this would be enough we do one better just to show that the filter system obviously also includes manual annotations such as tags:

And after activating the tag filter we are down to a single document. Nice, isn’t it?

A Few Technical Details

There are a few technical aspects worth mentioning about Alessandro’s work.

First of all: he makes direct use of Adam’s work on the virtual folders. The file list on the right is a simple KDirModel listing a nepomuksearch:/?sparql=… query. I find this very nice as my two students shared knowledge and discussed their work to find good solutions to their problems.

The second thing I find important is the creation of the filter list. The list of filters is created dynamically based on the existing annotations of the files in the current selection. In essence the idea is to only show filters that would actually change the list of available files (as you can see in the last screenshot this does not work 100% yet but we are close).

The GUI is obviously a prototype and we hope that you will give feedback and ideas to improve its usability. As Adam, Alessandro will continue working on KDE and Nepomuk and the smart file dialog will evolve until KDE 4.4.

Try It

To test the smart file dialog you need three things:

1. My kdelibs patch which makes the KFileDialog pluggable. This is actually a very simple one as the file dialog already loads the backend from a separate lib. While you are on it, please review the patch so it can get into KDE 4.4.
2. The Nepomuk-KDE playground module which also contains the smart save dialog. I recommend installing the whole module as the smart save dialog makes use of pretty much every Nepomuk lib available.
3. Tell KFileDialog to load the smartfilemodule instead of the default by adding “file module=smartfilemodule” into the “KFileDialog Settings” group of kdeglobals.

Obviously nepomuk needs to be enabled for it to work. Have fun.

GSoC Wrap-up Part 1

This year’s Google Summer of Code has ended. And it was a great success!

This year I had the pleasure to mentor two outstanding students: Adam Kidder and Alessandro Sivieri. Working with them was fun and rewarding. Both quickly understood what Nepomuk was all about and provided high quality work. I am very happy about that. Even more so since both of them plan to continue working on KDE and Nepomuk. Thus, I can only repeat myself: a great success.

Enough of the euphoria. Let us dive into the good stuff and start with Adam’s project:

Improved Virtual Folders

We have had the virtual folder KIO slave in KDE for quite some time now. But it was one big hack I threw together and always had its hickups, not to mention the lack of features. Adam took the project of improving the situation by making it more stable, introducing new features such as negated terms and relative dates, and providing a GUI for query creation. I can assure you that this was no easy task. Diving into the messy code I produced both for the Nepomuk query service and the search KIO slave Adam needed nerves of steel. But he proved himself by understanding and sorting out the mess and introducing a bunch of nice features.

Relative Dates

One of the nicest thing Adam implemented is the support for relative date in queries. By relative dates I mean for example yesterday as you can see in the following screenshot:

Virtual Folder using a relative date

Another possible relative date is “a week ago” which can of course also be combined with other query terms:

Apart from relative dates Adam implemented

Negated Query Terms

Using a minus sign as the negation prefix we can exclude certain query terms:

Querying for one tag

Excluding another tag

Very useful and mandatory for any search engine.

One thing I personally find very important is the possibility to use

Sparql Queries in the KIO slave

This allows to use the KIO slave to list arbitrary query results (as long as its only resources) and list them in Dolphin or even use a KDirModel to list resources in any application.

Listing Nepomuk Tasks via the Search KIO slave

Now let us have a look at the

GUI

Due to the complexity of Adam’s project’s code he did not get as far with the GUI as he would have liked. But as mentioned already he will continue to work on it and integrate it into Dolphin nicely. Anyway, so far we have a small query creator which allows to save queries that are then displayed in the nepomuksearch:/ main folder.

Editing a query in the simple query editor

Try it

If you want to test Adam’s new features before they are merged into trunk you need to install his work branch which replaces a few files installed by kdebase-runtime. The query editor is still part of the Nepomuk playground module. It is not enabled in the build system of the whole module, it needs to be built independantly.

That’s it for now. Next up: Alessandro’s smart file dialog.

Fixing Bugs is Fun

Yes, sometimes it is. And sometimes it is a good thing that David Faure does not answer your pings because it makes you write test cases. And sometimes these test cases actually reveale the bug you have been hunting for months. And sometimes searching for the bug makes you refactor and simplify code in the process. This is exactly what happend with the annoying “reload bug” of the Nepomuk query KIO slave. It was responsible for results sometimes not showing up before hitting F5 a few times. Well, that is history. The present brings a better design using a QWaitCondition instead of a local event loop (which was ugly anyway and I have no idea what made me using it in the first place) which as a side effect also fixes the bug and simlifies the code. (And I mean “simplify”, not “making it simple”. The code is still far from simple.)

That’s already it. Just wanted to share that. More search goodies when I blog about Adam’s GSoC work.

Nepomuk in the Summer x2

It is official now: Nepomuk is part of the GSoC with two projects. Yes!

• Saving and loading documents via metadata by Alessandro Sivieri
• Improving Search and Virtual Folders in KDE4 by Adam Kidder

Let’s make this Summer a good one for Nepomuk in KDE.

Thank You! (Nepomuk And The Google SoC supplemental)

It is very amazing how many ideas for Nepomuk GSoC projects were posted as comments to my last blog entry. Thank you, really! I read all of them carefully and transformed some of them into actual proposals. I did not use all of the ideas. Some of them were way too complex to be handled in one SoC project. But please do not think that I do not appreciate them. I will soon create a Nepomuk TODO/Ideas page on which you will find your ideas again.

But for now I think having 7 solid GSoC project proposals for Nepomuk-KDE is a very good thing. Now all we need is 7 students that all get accepted. ;) (And of course a bit of mentoring help.)

Nepomuk and the Google Summer of Code – second try: I want your ideas!

Comments on the last blog regarding Nepomuk and the GSoC were rare. Since I am not sure if that is due to a misleading blog title or due to an actual idea shortage, I am trying again.
Please post your ideas as comments to this blog entry. See the KDE GSoC ideas page to check for projects I already proposed. Go nuts!

Nepomuk in the Google Summer of Code 2009

Like last year and the years before that KDE participates in the Google Summer of Code. And like before project ideas are gathered independent from the Google process on techbase. And like last year Nepomuk will be part of the KDE projects proposing ideas. This is where you come in! I already posted two ideas in the list (scroll all the way to the bottom). That is not enough. I will try to come up with more but I think you have way more ideas up your sleeves (I noticed that much in Oslo where we had a lively discussion about the topic).

So, this is the opportunity to comment on this blog post and give your ideas for GSoC Nepomuk projects. You can, of course, even post the ideas directly on the techbase page (but then you should be available to mentor, too ;)

Thank you for your input.