Strigi Reloaded - The Answer to all our Problems? Hopefully to a few of them.

It took me one and a half day and Jos will not be happy about it. That is because I have to start this blog entry with apologizing to him:

"Jos, I am sorry, you will probably not like what I am about to present here. But this makes it so much easier for me and all the KDE people. And strigidaemon simply does not provide the needed features, which I can understand since you are doing this in your spare time. But I cannot wait any longer and in the end really want to reuse all the nice KDE features instead of reimplementing it all just to keep away from QT/KDE dependencies. I hope you understand."

Now that the tension is built up. What did this guy do? Well, essentially I reimplemented strigidaemon as a KDE Nepomuk service. Why would I do that? Why would I reimplement an existing working application? Simple. For the following reasons:

  • The parts that I copied from strigidaemon are rather small since all the work is done in the streamanalyser library. So "reimplementing" is maybe a bit overstating it.
  • Managing strigidaemon is not that easy as there is no proper method to suspend/resume indexing. You will see below why that is important.
  • strigidaemon does not inform about what it is doing. Thus, having an information GUI is impossible.
  • The new service is of course a Nepomuk service and as such, can make use of all our nice Qt/KDE features:
    • It uses KDirWatch to watch all indexed directories for change. In comparision the inotify/fam support in strigi was never completed and also meant to maintain 2 dirwatch implementation: one in KDE and one in Strigi.
    • It uses Solid to get notified about power state changes - indexing is suspended when your laptop is running on batteries.
    • It regularly checks the available space on the home partition and suspends indexing if the space runs low (also very simple via KDiskFreeSpace. Using Qt/KDE is so damn great! You really can focus on the important stuff!)
    • It shows info messages about its status via KPassivePopup. Very KDEish and smoothly integrated with the desktop.
    • It shows a GUI to inform the user that the initial indexing can take a while and gives the possibility to configure/disable/suspend/resume strigi (see below for a screenshot of the widget for which I'd like your input.)

For me these are more than enough reasons to commit the new service in the next days. It will solve the Strigi situation for many of our users that always disable/kill strigi because they don't get any information about it from KDE.

As I said above I wanted your input for the GUI. The idea was to make it non-intrusive but have it staying in a corner of the desktop until indexing is done or the user closes it. Here it is in all its uglyness:

[image:3572 size=original]

Please help me to make this widget useful.

Jos, I hope you can understand why I did it. It was rather simple and gives us all the features we need. Without reimplementing all the nice things KDE has to offer.


Sounds cool! Where does it store its data? In the Nepomuk Backend?

By gemuend at Wed, 07/23/2008 - 11:26

...does it store its data in Nepomuk. Well, technically it could use any strigi backend there is. But I hardcoded the nepomuk backend name.

By Sebastian Trüg at Wed, 07/23/2008 - 14:33

Reading this post, it sounds like implementing the daemon as a KDE service is an all-win.

What are the reasons somebody (Jos) wouldn't be happy about it ? Portability to non-KDE systems ? Other features ? NIH problem ?

By moltonel at Wed, 07/23/2008 - 11:27

I can only comment on what I remember from our discussions many month back. I think he liked the idea of Strigi being KDE/Qt independent. He wanted Strigi to stay a separately releasable package and feared that with a service like the one I presented here, strigidaemon would slowly die.

By Sebastian Trüg at Wed, 07/23/2008 - 14:35

I don't think the word "analyzation" exists--maybe "analysis"?

By Thomas K at Wed, 07/23/2008 - 12:04

hehe, you are right. See, this is why I need help! ;)

By Sebastian Trüg at Wed, 07/23/2008 - 14:32

I've to apologize Jos too because I'm really happy about this news. In fact during the last Strigi meeting I suggested something similar.
I've always been thinking that KDE's desktop searching program should be based on KDE/QT technologies. I think it will speed up the development (no more reinventing the wheel) and I hope it will attract more developers and bug fixers.

Now I'm waiting the code ;)

By Flavio Castelli at Wed, 07/23/2008 - 12:19

Seems joining two services will be smartest options and have still not known benefits. Great news!

What would I expect from Nepomuk config?

- Ability to enable and disable plugins as Strigi
- Showing current Nepomuk general state (indexing/not indexing) and ability to force change. Maybe 3 options: 1 Indexing, 2 Not indexing 3 Automatic (default). So when I have any specific need like wanting to get low disk usage I can force things
- A tool to check what Strigi is doing exactly by now and files afected
- A tool to check how much disk space is being used by Nepomuk

By brainsqueezer at Wed, 07/23/2008 - 13:47

What would you think of an advanced tab in the Nepomuk System configuration module that showed statistics and allowed to get an overview of running services? The indexing stuff could maybe also be handled in a system tray icon? And also via a DBus interface to allow Plasma plugins to show the status.

By Sebastian Trüg at Wed, 07/23/2008 - 14:37

That sounds cool! Seems to be the right place to me... until now I disabled strigi all the time because there was no good client which showed me a.) the progress b.) the indexed stuff

By lordbernhard at Wed, 07/23/2008 - 16:01