I have been neglecting this blog ever since GSoC started, but I think I will finally sit down and write about my progress. Also, if you read the entire post, you may find some screenshots at the end. 
Progress So Far.
So far I have only been working on backend-type code for the nepomuksearch:/ protocol. I have finished some important features that were missing, however.
Custom Default Search Queries
As an easy introduction to the world of KDE programming, I changed the hardcoded default search folders to be configurable in .kde/share/config/kionepomukuserqueriesrc (now that’s a mouthful!) So now instead of navigating to nepomuksearch:/ and seeing this:
You will see something like this:
where the config file looks like this:
[Searches] All searches=tag_nepomuk [tag_nepomuk] Query=hasTag:nepomuk
In the future this config file will allow you to specify additional options per default search.
Negation Queries
Next I implemented various improvements to the query parser and query service. It is now possible to use negative queries, both in the Lucene full-text index, and in SPRAQL requests. For example, I can search for documents containing the tag nepomuk but not the tag soprano with a query like this:
nepomuksearch:/hasTag:nepomuk -hasTag:soprano
Similarly, it is possible to search for resources that are not rated above a certain value.
nepomuksearch:/-numericRating>8
Of course, this is pretty silly, as this is equal to using <= (in fact, in the SPARQL generation, this is exactly what happens). It is also possible to use negation queries in full-text queries with the same syntax:
nepomuksearch:/hasTag:nepomuk -gsoc
This will return all resources tagged with the tag nepomuk without “gsoc” in any indexed field. Of course, there is a caveat: Lucene only allows queries with at least one positive term, so only specifying only a negative term will give you zero results, rather than all resources not containing that term. This is not generally a problem – only specifying a negative term will return many many results if your entire home folder is indexed, which is not generally very useful.
Date Parsing
Up until now, there has been no method to specify dates in a nepomuksearch:/ query. This means there was no possible way to say “show me all resources modified after yesterday.” I’ve built upon (read: shamelessly stolen ) some work that Sebastian Trüg has done for Scribo to implement a generic date/time parsing framework for use in Nepomuk. This means queries such as
nepomuksearch:/sourceModified>"July 26"
will now work properly. This is still quite raw, and will be seeing many new things soon. One of the features I’m working on is support for relative dates and times – that is, instead of specifying a date such as “June 30″, you can say “yesterday”. This will allow you to make a virtual folder containing all resources changed after yesterday that will always stay updated. Wait a minute, you might say, this is already possible – one of the default search folders is “Yesterday’s Files”. These default folders are hardcoded, however, and there is no method to make a query like this through a nepomuksearch:/ query string.
Next Steps
While there is still some backend type code to work on, I’m starting to working on the new UI for search. Here is my first UI mockup:
The idea is that when the user types a query into the search box, the advanced search pane drops down. The user can select a search criterion in the first combo box, and an appropriate set of relations will appear in the second. The third field will contain an appropriate input field for the type of date: for tags, a button to bring up a tag cloud, for dates, a date widget that brings up a calendar, etc. Users can press the “+” and “-” buttons to add and remove criteria to the search.
Instead of a breadcrumb type display for the location bar, Dolphin will simply display “Custom Search Query”. Upon a click, just like in the breadcrumb display, this will change to show the actual URI.
Any thoughts, improvements, suggestions, flames? Please post them in the comments! This will also be cross-posted to kde-usability.