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.
Syndicate Blogs
KUIServer
What about using KUIServer. If I understood correctly one can use it to stop/pause/restart jobs, if KJob is used for it.
Hard work / transient dialogs
Well, at least Jos' hard work has not gone to waste, since most of that went into libstreamanalyzer and the analyzers. And, importantly, a GNOME version of the strigi daemon could be created that used the same analyzers. On that point, is the storage of the indices done in the same way that strigidaemon does it?
As for the popup, I think it should be replaced with a passive notification that it is running, together with a pointer to System Settings to change options or disable it.
The trouble with one-time transient dialogs is that they don't help users find the configuration later on to re-enable something they've disabled or change other settings.
GNOME version...
If I understand Jos' design decisions correctly, the whole point was to avoid having to do a "GNOME version" of the daemon. It's designed to be desktop agnostic and hence has no dependency on KDE.
Systemtray?
So what do you think? Should I add a systemtray that shows an animated icon during indexing and allows to suspend/resume/configure? Or should I not provide any specific GUI with the service but only passive info messages in combination with an arbitrary GUI thing that communicates over DBus? The latter can then be a systray icon or a plasma applet or whatever.
I am not sure what is best. I systray icon is traditional which has its advantages and disadvantages... but the service also has a proper DBus interface including signals that inform about the state.
I'd go for the latter.
I'd go for the latter. Personally, I don't want yet another icon in my system tray for something like indexing. I had enough of "system tray icons for everything" in Windows.
No doubt someone will create a plasmoid for montioring the indexing service, which people can install if they want.
Some UI Issues
A few things that might annoy me about the dialog if it popped up on my desktop today:
1) The disable button isn't clear on whether it's talking about disabling the dialog or the search. (The checkbox makes this a little bit clearer, but not terribly.)
2) There's no way to dismiss the dialog and have the search continue. I would think this would be the common case of what most users should want to do with this dialog. (Can you just click on the notification to close it?)
3) I'm not sure you should have a button to disable the entire search feature so quickly. (Assuming, indeed, that this is what the disable button actually does...) Users will have trouble turning it back on again if they disabled it from a dialog. (Either if they accidentally click it for some reason or they change their mind later because their desktop turns out to be less functional without the search feature.) Have them need to go into the configure pane for strigi or nepomuk (where-ever it is that the configure button sends them) if they want to disable it instead. Suspending from the dialog seems reasonable though.
4) I don't like the need for this dialog. Especially not everytime it starts indexing. It's absurd that as a user I should be notified everytime a service does indexing. If I've asked it to do indexing it's because I want it to do it, I don't want it to tell me about it all the time. Do you know of any other search indexing thing which is nearly so noisy when it's indexing? Updatedb doesn't tell me when it's running, neither should strigi. If this dialog is necessary because of the slowness that an indexing is causing, then this indexing should be happening with the proper nice and ionice classifications so that it isn't interrupting the responsiveness of my desktop. (ionice is supported since kernel 2.6.13. So it's been around longer than inotify.) If manipulating your program's ionice and nice priorities isn't possible within Qt at the moment, then it should be added to kdelibs and pushed to Qt as soon as possible. (Or pushed directly, if that's easier and will get the feature in just as fast... I don't think this is something that should have to wait for Qt 4.5 and for the KDE project to switch to it.)
Otherwise, this is good work and it's nice to see progress here.
(Jos, I don't know who you are and have never talked with you, but I'll add my sympathies to the growing pile. I know what's it's like when people run away from what you see as the *right* architecture to a different solution. If you still have concerns about whether the strigidaemon will survive, perhaps you should push that part of the project into the freedesktop project?)
Some answers
1) agreed.
2) ATM the dialog goes away if you check the "dont show again" checkbox. Not very standard. But that is why I am asking. What would be a good way?
3) It does not disable the search, only the indexing. But maybe you are right, and suspending is enough for this dialog.
4) The idea is to show this during initial indexing, not everytime it is updated. The reason is that even with nice and ionice (both used) people get very jumpy about strigi when they do not know what is happening. It is not about the slowness of the system, but the load. People get scared or angry. So we need to inform them. Comparison to stuff like updatedb IMHO does not really stand. The file indexing is a much longer process and is something that users can change for themselves.
An interesting set of problems.
It sounds that the real problem you're trying to solve and the purpose of the dialog is to let the user know Stirgi exists more than to actually implement any particular feature. Once users get used to the idea of Stirgi, they might not need this type of dialog anymore?
In that case, perhaps it would be best if there was a plasmoid that started on the desktops of new installations that listed small messages about different newish things in KDE and offered a few buttons that a user could click to directly take them into the configuration for those items. (Is there already a new installation plasmoid in the process of being made? I thought perhaps there was... anyways...)
The plasmoid could be called "New Features / New Tips" and could contains various little notifications, kind of like below:
(Render this in your head as different little extenders in a containment (I know very little about plasma, so my terminology might not be correct) that each have a title, some text and some buttons attached. Once the user feels comfortable they don't need it anymore, they simply close the plasmoid.)
New Features / Tips
== Stirgi ==
Stirgi is our new file indexing and file searching service. It's now looking through all of your files to try and get an idea of what's on your computer.
[Configure Stirgi] [Suspend Indexing]
== Plasma ==
Plasma is KDE4's new desktop technology ... blah blah blah....
[Configure Plasma] [Add Plasmoids] [Add FolderView to Desktop]
== Solid ==
Solid is KDE's new thing, that does things that I still don't know exactly what it does.
[Configure Solid]
== Improved Network Manager ==
Hopefully by this time we wrote a network manager of some sort that just works a whole lot better. (I know KDE has one, but it's being cleaned up right now, right? Hopefully in time for 4.2?) As usual, doing this across distributions is almost impossible, but we're just that good!
[Configure Networking]
This way, it's non-blocking, shows up when it might be needed, goes away as soon as a user is comfortable with Stirgi, and complies with the same UI that the rest of the extenders will have... which means the user will either be used to it, or will get used to it soon enough.
(I'm making an assumption here the initial indexing happens soon after the user logs in for their first time anyways? Even if not... the plasmoid/extender can go ahead and update itself dynamically...)
About that.. yesterday
About that.. yesterday installed Google Desktop at family computer. First index is not like in previous versions. You don't really notice it. How do they do that? Maybe should wait for computer to be idle or is there any way to it in an slower less disk and processor aggressive? User doesn't really gonna try Nepomuk just after installing KDE4.
Seems joining two services
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