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.
Tags: KDE, open-source



Very cool stuff!
About the search query UI, I always found the filter widget from the application Imagery (http://xerto.com/imagery.php) very interesting.
Here is a screenshot: http://xerto.com/images/screen-shot.png
Maybe it gives you some ideas.
Christian
Really great work! I joined the Nepomuk coding sprint 2 weeks ago and we discussed already a little bit the UI for advanced searching in Dolphin. It goes in the same direction as your mockup shows, but some things are missing we’d like to integrate (e. g. option to search only in sub folders, a “Save” button to save the current search configuration as default).
It would be nice if you get in contact with me before investigating too much work into the UI code. I’m quite busy until the end of July with non-KDE things, but I’ll be able to discuss and code afterwards -> should be no problem to integrate this into KDE 4.4
Thanks!
Great work. Also very pleased to see the graphical input thing.
For the graphical input it would be good to have in the first dropdown box (the one with “date modified”/”Size”/”Comment”), logical options “all of” “any of” “none of” “not all of” (perhaps the last of these is not necessary).
All of being the default of course
Approx layout:
[Date Modified]:::[is greater than]:::[1/1/03 12:00AM]::[-]
[Any of]::[-]::[+]
:::::[Size]:::[is less than]:::[10]::[MB]::[-]
:::::[Type]:::[image]:::[-]
[Any field]:::[contains]:::[totally awesome ]::[+]
Note there is a “+” by the add items entry to add items to that list as well as the usual “+” to add items to the bottom.
Oh dear, I’m sure I haven’t made it any clearer but you’ve thought of it already.
OK Googled it and OSX does exactly this:
http://mactoids.com/wp-content/uploads/spotlight-boolean-filter.gif
I don’t care about your search-gui, in my opinion the real power of your work is when apps like kmail allow such a query (preconfigured for realistic queries in a mail application). That will really rock.
You are now laying the foundation stones, and that is realy cool!
About your mockup: For a complex query it is fine. I would use that big white widget (QListView)? I would prefere something like this:
http://tuxtraining.com/wp-content/uploads/2008/03/tracker.png
That Tracker-interface is easy to understand and not ugly
“I would use that big ”
^^^^make that “I wouldn’t use that big…”
It really looks great; I hope it becomes Useful as in Apples Finder, the “Custom Search Query” remembers me in the finder! NICE WORK
[img src="http://www.geekology.co.za/blog/wp-content/uploads/2009/05/apple-finder-spotlight-search.jpg" width=400]
This is great! This has been missing from KDE 4 from the beginning and will finally make nepomuk/strigi _really_ usable “for the masses”.
Btw: I have no background in usability but I think the user interface is intuitive and obviously very powerful. However, you might want to add an “Advanced” button next to the search field to display the advanced options instead of just displaying them when there is text in the searchbox. (The user might want to look for e.g. all files with a certain modification date but does not want to search for a specific text just like you pointed out in the article)
Great to see! You may already have noticed them, but I made some mock-ups of a possible search (and/or filter) interface for Dolphin. They are in kde brainstorm, but here is the link to the relevant thread:
http://forum.kde.org/viewtopic.php?f=83&t=38890
The mock-ups are shown for filtering a folder, but they were designed to apply equally well to both searching (with nepomuk) and filtering. You can see there is a “filter” and “search” button, this allows you to switch between the two. There is more on that in this idea:
http://forum.kde.org/viewtopic.php?f=83&t=38887
@TheBlackCat
Thanks! I’ve posted a link there about my ideas here.
That looks great!
Finally an easy ui to use Nepomuk.
Does the date parsing support languages other than English?
@Niklas
Unfortunately, it does not (yet). This is definitely on the todo list, and will probably be present in some capacity when this work hits trunk after GSoC.
I did a quick mockup on how I think it could look
http://imagebin.ca/view/LzwnvQWh.html
What do you think?
Действительно интересно написано, но мне кажется, что все-таки автор что-то не договаривает