Faceted Browsing in KDE or The Blog Entry that Missed a Catchy Name

It is about time I blogged again. So I will just blabber out what I was doing for the last two days: Facets – again. Why again? Well, this is my third attempt at creating a generic facet framework for KDE and the fifth in total I think. Alessandro Sivieri started writing smart facets in his GSoC project 2009 (yes, I will write a summary of GSoC 2010 – I will get there eventually), then continued with a simplified version in his SemBrowser. Then I stepped in, trying to make his facets generic by separating GUI from core which looked nice in the beginning but eventually failed since certain things could not be solved when separating GUI and core. In the end I decided that Facets are a very GUI kind of thing and went back to Alessandro’s SemBrowser design of facets: each facet is a QWidget.

And that is what I did the last two days. Now I have a FacetWidget and convenient subclasses ListFacetWidget, SimpleListFacetWidget, RangedFacetWidget, and DynamicListFacetWidget. The basic idea is (following Alessandro’s approach) that each FacetWidget provides one Nepomuk::Query::Term. The combination of all terms (and some optional base query) make up the final query.

Before I continue let’s have a look at how this looks like at the moment:

Preliminary Facets in Dolphin

The GUI is not very impressive yet but I am rather fond of the underlying techniques. Each FacetWidget has a method selectFromTerm which tries to use the provided term to configure the facet. A simple example: the SimpleListFacetWidget compares the provided term to each of the term in its internal list of terms and if one matches it selects that one. So in other words if the following call succeeds:

if( facetWidget->selectFromTerm( myTerm ) ) {
    ....
}

Then a subsequent call to

facetWidget->term();

will return exactly myTerm. This allows for extracting facets from any query. This is what the FacetWidgetController does. It provides methods and signals to handle a set of facet widgets through one interface. And since we can extract facets from any query we can provide faceted browsing on any query listing without remembering some state. This is where KIO::UDSEntry::UDS_NEPOMUK_QUERY comes in which allows KIO slaves to communicate the query which can list the current folder contents. This is simple for nepomuksearch:/ but also used by timeline:/. For file:/ we have a default query listing all files in the one folder. This query is then picked apart by the FacetWidgetController, allowing users to use facets on any local folder listing.

Again let us look at a simple example – timeline:

Facets extracted from timeline:/ listing

As you can see the one facet used in timeline:/ (namely the restriction by date) has been extracted from the query. Selecting additional facets will keep the date restriction and continue from there.

I think this is already a pretty nice system. Next steps include polishing the API, adding some dynamic facets (such as: image size once Images is selected or a way to restrict Media files by author/interpret), and a nicer GUI. This is where I would love some feedback – the GUI takes way too much space and needs some beauty.