[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Access indexing
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2012-02-24 23:44:50
Message-ID: 0DE898A0-2FDE-4BD8-9270-8F68D3D2DF3D () gmail ! com
[Download RAW message or body]

On 25/02/2012, at 12:46 AM, Stephan Menzel wrote:
> Just imagine the following use case and maybe it's getting clearer then:
> =

> I sit in a meeting room with my laptop and conversation turns to the
> subject "Project Vulcan" ;-)
> Now I know I was having some pictures I took somewhere on my computer,
> along with meeting minutes of previous meetings. Since I am unable to
> organize and name files correctly  I just wanna see what I've got
> about 'vulcan', by very quickly entering the text somewhere, without
> having to break conversation because I start fiddeling with the shell
> and 'find' and I immediately got a list of files with the text
> 'vulcan' in their names. If I wait a little longer there will be more
> hits such as text with 'vulcan' in them and vulcans in my address book
> and so on. I want a list, click on any entry and open the appropriate
> file.
> If any of you happen to have a macbook or an iphone, just try that
> search field. It's terrific.

Yes I do (have a Macbook).  The search function is a small magnifying
glass icon at the top right of the screen (equivalent to a "systray" item).
It drops down to single line-edit type field with the label "Spotlight".

Within a day or two of acquiring the Macbook I tried it out and found
that it had already indexed all my old KDE emails.  No fuss, no bother,
no using up the whole of one core continuously.  It just gets on with the
job.  Like a Google search.  I do not use it a lot, but it is nice to have.

I was waiting years for something similar to go with Nepomuk, Strigi,
Soprano, Virtuoso, Rasqal, Raptor (and on and on)=85  The chain of
dependencies is soooo cumbersome and everybody who wanted to
compile the latest KDE libs had to carry it.  In my case there was no
benefit, just a lot of downloading and compiling.  I used to dread
having to rebuild KDE libs.

Even on Macbook I am not totally immune from the Strigi-Nepomuk
complex.  My Macports kdelibs 4.7.4 port contains all that stuff, pointless=
ly,
and the complex dependencies also cause problems for the Macports
team from time to time, and also for ports of really nice KDE applications
such as KMyMoney and Digikam.

I am surprised too that Nepomuk, Strigi et al. require so much CPU
power and space.  This is not at all what was claimed at Akademy
2007, akademy2007.kde.org/conference/slides/strigi.pdf  See the
slide entitled "Speed Comparison".  What went wrong?

Cheers, Ian W.




>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]