For the record, work is ongoing to create an alternative control panel to allow for more customizability (and the main developer offered to review the code himself).

I think that this should end the discussion in the most constructive and fruitful way:

http://lists.kde.org/?l=kde-i18n-doc&m= ... 517499&w=2

Many thanks to Vishesh for hearing to our appeal.

Just for what it's worth:

I like the idea of indexing a lot and (at least on my machine with an Arch build) baloo is already working much smoother than nepomuk/strigi ever has.

But: I still don't use it.

For me the issue is not being able to turn it off (that seems like an obvious necessity like others pointed out very convincingly).
The point I am much more concerned about is the lack of control and transparency at the moment. Well, it's new, - there might not be an advanced options GUI yet, I get that... I am not afraid of editing a .conf file (I guess noone writing and reading here is...). So please, give as some comprehensive documentation. As Vishesh Handa mentions in his blog there is a .conf file to control it (which dolphin using baloo couldn't find, .... haha, go figure ...).

So my question is:
Where is this file, how to use it and where do I find documentation?
(any Google search I do only finds "how-to-switch-things-off"-threads or general blabla...)

I am ready to give it a chance (as I said: I like the idea) but not if I don't know what it's doing (or is supposed to do...)

For many reasons I (that's just me personally) I want to control WHAT is indexed to a level that no default setting can guarantee.
Maybe I just want to hide those porn file titles while I am searching for a movie to watch with my girlfriend sitting next to me, maybe I really don't want to take any chance that a potential customer might see other customers documents names pop up up briefly in the results of searching for my offers to him while presenting stuff live, maybe I want to search for .conf files with valid read permissions over different snapshots and system partitions, maybe I give files in multiple versions a custom file extension and don't want to find hundreds of in-beetween-versions files, or I simply want to reduce searchable index to stuff that's really relevant to me. These are my concerns... on my machines... for my way of doing things... should be subject to solely my decision and understanding ....

Now a point that's really invalid, is to say that by excluding directories I can achieve a lot of these examples (and many more), I only have to organize my data in a more consistent directory structure. But that is denying the whole really new (revolutionary one might say) point of active indexing and live desktop search:

You should not need to hierarchically preorganize your file trees and directory structure to reflect the purpose or content or type of the files you want to keep.

In a perfect world you might just dump everything in one folder and organize by searching and filtering. At least unclutter the depths of your directory trees. By giving us the only configuration method to exclude (where the heck is the INCLUDE option ?) by directory defeats this whole purpose.

That's my cents... but let me repeat my question:
Where are these configuration files and how can I use them to control and/or understand what exactly baloo is doing regarding the content of the search index it is producing?

thx for reading,
best regards,
piedro

piedro wrote:That's my cents... but let me repeat my question:
Where are these configuration files and how can I use them to control and/or understand what exactly baloo is doing regarding the content of the search index it is producing?

thx for reading,
best regards,
piedro

Please try this advice:

http://lists.kde.org/?l=kde&m=139783082508669&w=2

thx for the hint. I already found and checked out this file. As I said I like to configure it and I can see a few "exclude"-settings in the file and I understand I can add some more.

But where is the documentation? What is the correct format for "exclude-mime-types"? Does this file allo regular expressions as "please exclude all log files from this directory but include from another"? and so forth ... at least I can guess what it's doing now ... and I have to say after reading the devs blog, as mentioned above, I expected a far more refined exclusion pattern... For example: I want "*.orig*" files to be included. I am happy to see the intended default settings of many rc and conf-files and I always make an copy to "<configfile>.original" before editing ...

As I see it, the lacking of comments and documentation and the sparsity of the settings themselves within this baloofilerc file does exactly proves my points!

Since when has it become acceptable within the open source community to produce vital configuration files without any comprehensive comments regarding options and how to edit the file (also the purpose, version and date of the file) ... who could manage to administer the system configuration of any linux box without these common sense good practices. And who could take over a project after a dev looses interest without these?

Best regards,
piedro

piedro wrote:thx for the hint. I already found and checked out this file. As I said I like to configure it and I can see a few "exclude"-settings in the file and I understand I can add some more.

But where is the documentation? What is the correct format for "exclude-mime-types"? Does this file allo regular expressions as "please exclude all log files from this directory but include from another"? and so forth ... at least I can guess what it's doing now ... and I have to say after reading the devs blog, as mentioned above, I expected a far more refined exclusion pattern... For example: I want "*.orig*" files to be included. I am happy to see the intended default settings of many rc and conf-files and I always make an copy to "<configfile>.original" before editing ...

As I see it, the lacking of comments and documentation and the sparsity of the settings themselves within this baloofilerc file does exactly proves my points!

Since when has it become acceptable within the open source community to produce vital configuration files without any comprehensive comments regarding options and how to edit the file (also the purpose, version and date of the file) ... who could manage to administer the system configuration of any linux box without these common sense good practices. And who could take over a project after a dev looses interest without these?

Best regards,
piedro

Regretfully, the details were not shown to the Documentation team until the release and we do not have much members to test everything.

There is a draft by Burkhard Lück:

http://lists.kde.org/?l=kde-doc-english ... 914474&w=2

But no reply from Baloo devs so far. I guess the only way to reach the inbuilt settings now is to study the code:

http://quickgit.kde.org/?p=baloo.git

Thx a lot for the clarification!

Regretfully I can't read code... though I see a lot of activity there - at least that's kind of promising ...

I really suggest the KDE publishing team should treat missing documentation as a relevant missing feature. In a sense that software without comprehensive handbook or webpage or outdated information should be excluded from being published in "stable releases". There is plenty of techsavy users that are willing to test beta releases but for any user without the resources to really try to understand what's going on in his/her system the pratice as is to just throw in a complete new technology including new UI elements and new ways of configuration WITHOUT any explanation (which makes it impossible for an ordinary user to troubleshoot) his /her system - that is a major frustration to users.

I understand that devs often don't care - well, I don't have to use there stuff, right? But for a major project like KDE that is only partially true. I might want to continue using KDE and benefit from the bugfixes and improvements of other parts of the project and have no way of deciding not to use that specific funcionality.

That is hurting the project as a whole and even if devs often don't care too much about users (which is there right to do, I guess) they might consider hurting other devs like the KDE PIM guys that do an admirable job cleaning up the Kontact mess. Users do not discriminate: If things like (mail searching for example) do not work they get frustrated with the whole project not only the baloo team.

So in the interest of the integrity of KDE, I suggest: Treat documentation as essential part of the project and do not publish undocumented parts (except in beta and test releases that aren't addressed to the public).

Thx for reading,
piedro

p.s.: I should open a suggestion thread, I guess... I do not find the right place in the forums... where should I post stuff like this?

The developer has documented the config file:

http://community.kde.org/Baloo/Configuration

The location of the file is

~ /.kde/share/config/baloofilerc

Assuming ".kde" is your kde prefix.

On a related note: how to disable Search has been documented quite a while ago on userbase.kde.org.

I put it there, but I honestly have no clue how otherwise documentation works in KDE so I didn't do anything else... Sorry. On the other hand, it seems rather obvious to me that if you don't want Search to index your home, add your home to the 'do not index' list and it will be disabled. I think you're all just thinking too complicated

To write something constructive, as suggested:

My use case is, that I have to frequently organize and reorganize huge amounts of files for archiving. These are mainly emails but here and then a big chunk of docs or pdfs also. After I reorganize the directory structure, delete a lot of files (mainly emails) I send the whole bunch of data back to the people they belong to. Cause they aren't mine, it's for customers and coworkers.

Apart from the fact, that working with kmail alone doesn't cut it (yet) for big email archives (50k+), I certainly do not want any of this stuff indexed.
For one it's a breach of data integrity and secondly it's just annoying to have indices of other people's stuff mixed with mine.

Now after searching through lot's of information about baloo, I am able to switch off file indexing for my work folders, even do some limited configuration. Though I don't get why any publisher of software assumes I don't need this and why I had to go through heated forum discussion to simply find brief documentation how to switch off this service (or modify it to an extend that I can work with) - it works now for me.

But as it turns out that's only half of the truth because now my system freezes because of akonadi_baloo_indexer. Searching again I found the hint to use akonadi console to remove the akonadi baloo indexing agent. That was easy after I 've found out. Next start of my system (or akonadi, or kmail, who knows?) the agent is happily running again using 3.6GB of RAM, giving me a hard time to even shut down my system which is already heavily swapping while indexing (a deadlock situation if you think about it.). So now I am looking for a way to permanently disable this baloo akonadi agent. Haven't found it yet - loosing more and more time on sonething that probably will be change soon anyways ... (and that would be only a workaround because I still want to use autocompletion ans searching for emails - just only for my own contacts!)

That is my use case and my established workflow atm is seriously hindered. Indexing is a great tool for emails and for files but the whole point of indexing is organizing relevant information in a way that is meaningful and useful to the user. Nobody apart from myself knows what is relevant, meaningful or useful to me! Devs as caretakers for what's good for other people is a rather strange myth.... though I respect their effort to try to make useful stuff as they believe it might be useful for others...

As stated many times before:
- there really is rational justification for denying any "switch it off"-solution
- there is also no justification to publish as stable if it's clearly not - lacking functionality, lacking indiviual usability, lacking documentation and, most importantly, lacking stability. (As I saw on some bug reports: baloo_file_indexer and akonadi_baloo_indexer have known to lock up systems long before the stable version has been released)

I wonder if there will ever be the day, the dev community establishes a user friendly standard for their releases. I'd really love to take KDE as a reliable source of software I can trust to be configurable, stable and integrated. Beautiful it is already ...

thx for reading,
piedro

In terms of not indexing the folders which contain your work material - I suggest adding them to the Blacklist. This can be done through System Settings.
As for email indexing, you should be able to disable that in System Settings as well if I recall correctly (haven't yet updated).

I am very happy that obviously there is an option now in systemsettings to disable baloo file indexing within the systemsettings.

I am not sure whether this settings also affects the indexing of mails but as the baloo processes seem to be fixed regarding their memory usage (hogging up system memory) -
I have no further issues with baloo - on the contrary: I am quite happy that it works already much better than nepomuk ever did!

Still comprehensive documentation would be very much appreciated...

Solved for me,
thx to everyone working on this for the progress,
piedro

piedro wrote:I am very happy that obviously there is an option now in systemsettings to disable baloo file indexing within the systemsettings.

I am not sure whether this settings also affects the indexing of mails but as the baloo processes seem to be fixed regarding their memory usage (hogging up system memory) -
I have no further issues with baloo - on the contrary: I am quite happy that it works already much better than nepomuk ever did!

Still comprehensive documentation would be very much appreciated...

Solved for me,
thx to everyone working on this for the progress,
piedro

Good to know, Piedro.

In terms of documentation, help with keeping this page updated with all the latest issues and changes (incl those discussed in this thread) would be appreciated: http://userbase.kde.org/Nepomuk

(hint: it is already outdated!)