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

List:       kde-devel
Subject:    Re: Access indexing
From:       Stephan Menzel <stephan.menzel () gmail ! com>
Date:       2012-02-16 12:12:28
Message-ID: CAEQ568vE7-+s_80vNG_E7QmJzKhuffjjP+6oQKvxUYUFQ7u-5g () mail ! gmail ! com
[Download RAW message or body]

No, this wouldn't cut it. There's several reasons:

1)
Maybe I described confusingly. I want it to search for arbitrary
filenames (not just applications) and similar expressions _fast_.
Instantaneously, as the apple thing does. There must be indexing for
this. Also, besides filenames it shall display search results in meta
information as well.

2)
As I said, it's a fun project. I have seen for years that I can live
without it, so the need can't be too bad. It's not really for
publishing either cause I'm not keen on Apple to sue my ass ;-) So
it's just to get to know the system and for that it's irrelevant if
there is a workaround.

3)
I have a strong problem with the Nepomuk/Strigi/Indexing business KDE
is doing. I have used KDE for more than a decade now and I really like
the way KDE is going with sematic desktop, metadata indexing and all
this. However, I do think quite frankly the way it's presented to the
user is catastrophic. No offence, just my opinion. As soon as Nepomuk
is active, it's eats up one of my CPU's entirely. All the time. When
the indexer is active, it gets even worse and both CPUs are used,
along with plenty of IO. I have seen this behaviour ever since I first
installed KDE4 (I remember this was an early 4.2) and it hasn't
changed much. This would be almost acceptable if real usability would
come along with that. It took me ages (and lots of googling and
asking) to figure out how I can actually access this indexed
information. As far as I am aware of it's via the 'search' button in
dolphin. Which IMHO isn't nearly enough to realize a semantic desktop
concept. There may be other ways but if there are then I don't know
about it as a long time user, which just proves my point. And I
believe the first step to make this better is this very simple
plasmoid. Just a line to enter whatever you want and the system tries
to find relevant stuff in your files. Simple. It might just enhance
the presence the indexing has in the user's perspective and thereby
justify the immense resource hunger this has. Up to now, I simply
deactivated all of it. I know, I can do this, I don't pay for it. But
then I would love to see improvement there and I was just wondering if
I can contribute with that seemingly simple thing. The goal here is to
create acceptance (and may it be only my own) for the resource demand
of the semantic desktop system.

Does that explain it a little clearer?

Cheers,
Stephan



On Thu, Feb 16, 2012 at 11:55 AM, Todd <toddrme2178@gmail.com> wrote:
>
> Why aren't you using krunner? It already has most of this functionality and
> much more in a more modular and extensible form.
>
> There is already a krunner plasma widget you can put in a panel on
> kde-look.org.
>
> If krunner is missing specific features it would be a lot easier to add a
> new runner than to recreate krunner from scratch.
>
> -Todd
>
> Stephan Menzel <stephan.menzel@gmail.com> wrote:
>>
>> Hi KDE team,
>>
>> as a fun project and to play around with Plasma and Python Bindings, I
>> am developing a plasmoid (in python) that I was always missing since I
>> first saw strigi digging through my file system. Basically, it is a
>> remake of a little tool Apple is offering in OSX. They have a simple
>> line entry in the upper right corner of a desktop and when you enter
>> any text it looks in local indexed file names, contents, meta
>> information, contacts, anything you can think of for the search entry.
>> I always wanted this for KDE and I thought it might be good thing to
>> start with.
>>
>> As the UI is fairly simple I quickly got to a point that I actually
>> want to access the index databases and here's where I would need
>> someone to point me in the right direction.
>>
>> I was looking through the docs and the way I understand it, there will
>> be
>> multiple sources I need to query. Nepomuk calls that type 2 and 3
>> meta information that I will definately need but the first and far
>> most important thing is file names. So I'd like to start with that. I
>> understand the Strigi file indexer runs through all my files,
>> extracting meta information for the Nepomuk database, right? So is
>> there a preferred way of accessing this index? Strigi is not listed in
>> the kde python bindings but I might write my own for that. The project
>> information / website are a little sparse so is that what I need to do
>> or is there another access point? I don't need file content at this
>> point but I do need to have some sort of search functionality upon
>> this index.
>>
>> Any hints are greatly appreciated.
>>
>> Cheers,
>> Stephan
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<<
>>  br
>> />
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

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