[Digikam-devel] digikam and search ioslave

[Renchi Raju]

On Friday 10 June 2005 04:24 pm, Xavier Helluy wrote:
> I am the author of kio-clucene http://kioclucene.objectis.net , a search
> ioslave for kde. It is still a pre-alpha software, but it works. It can
> store preview of all images, and query all metadata, using boolean search
> if necessary. The query syntax it uses is versy similar to wikipedia:
> example:
>
> clucene:/ +mimetype:png +author:bla -date:[2002 2003]
>
> I read some time ago that you were implementing search inside digikam.
> I wonder if one could not make use of my ioslave to allow searching from
> digikam and outside of digikam.

digikamsearch ioslave has already been implemented. In addition on the 
frontend side, a quick search dialog is ready and advanced search dialog is 
being implemented.

http://pooh.tam.uiuc.edu/digikam/digikamsearch-01.mpeg

> A while back I indexed via the digikamtags 
> ioslave my digikam image albums. I could search on on tag names and
> metadata. But this was difficult because of the way the digikamtags ioslave
> names its path and it is impossible to know when a tag has changed or not.
> I finally removed the code, (which got broken for other reasons). So
> indexed data can get out of sync really fast So if digikam would be
> responsible for indexing its albums, or would notify the world when new
> tags are created/added, this would be great.

the db backend for digikam was changed recently and all the albums and photos 
are indexed currently. how often do you index the data?  it might be possible 
for you to watch the digikam3.db [poll, directory watch, or other option] and 
get updated tags, albums.

> What might not work (but untested and for me maybe difficult to code, but
> could be enabled one day, when substring queries like *bla will be
> implemented inside the ioslave) is a search-as-you-type. But I have read
> you are not looking for such a design right away.

this has already been implemented (as you can see from the video) and most of 
the search which is not an exact search is a substring search.

> I think trying to output the searchable-data-information, while having
> application-specific search-dialogs would be nice for kde too. One could
> then even imaging that one could switch betwen different kde search-dialog
> according to what one is looking for (like a general multifield dialog, a
> image specialized dialog,...). Ok I am being confusing now

I'm not quite sure the level of collaboration you are expecting. We are a 
specialized app and have specialized needs :). In addition, there is the 
tenor project also coming about. But that should not stop us from sharing 
ideas.

renchi