Bug 334026

Thanks for the report!

(In reply to comment #0)
> I, (and others probably), do not wish to use baloo at all - i.e. un-install
> the complete package. This is not currently possible without breaking
> Dolphin (amongst others). 

Sorry, but this is wrong - even if Baloo is not installed on the system, Dolphin can be compiled, installed and used perfectly (without any of the features provided by Baloo of course). The Dolphin packages that most distros provide might have Baloo as a hard dependency, but you can build Dolphin yourself without Baloo if you want. If there is a huge demand for a Dolphin without Baloo support, someone might already be providing such a package in an add-on repository for your distro. Everything that can be done on our side to make such a thing possible has already been done.

OK - Thanks for that.  Better start learning how to build Dolphin myself then.

As an aside. (Tongue in cheek rhetorical question).
I wonder what percentage of average users build their own packages?
I wonder what percentage of average users wish to un-install baloo?

Regards, Paul

(In reply to comment #2)
> As an aside. (Tongue in cheek rhetorical question).
> I wonder what percentage of average users build their own packages?
> I wonder what percentage of average users wish to un-install baloo?

Sorry, but could you please explain what Dolphin-related point you are trying to make with these questions (please do not forget that this is a Dolphin wish report)?

Great care has been taken to ensure that Dolphin's build process will check if Baloo is available on the system where it is built, and simply disable Baloo support if that is not the case.

In other words (I might be repeating myself here):

Everything the Dolphin team (which just provides the source code, nothing else) can do to enable you to use Dolphin without Baloo has already been done. If you are still unhappy with the situation, please accept that is is not our fault, and stop trying to make us feel bad with "tongue-in-cheek rhetorical questions". Thank you.

Firstly, I apologise to yourself and the Dolphin team. I was not intending to make anyone "feel bad".

The point of the rhetorical question, was, I thought, obvious. It should not really be necessary to build Dolphin oneself to enable a baloo free system. 

Integrate semantic data by all means, many users I'm sure will use and benefit from it, however, there are users who prefer not to. Dolphin is user configurable to a large extent, choice of previews and services for example. I would have thought it would have been a trivial task to have offered an option within set-up to, for example: "Use Basic File Information Only" in the information panel. Basic as in the information comes purely from the file system - indeed as it did before the introduction of the previously nepomuk and now baloo widget.

As I said, I shall have to learn how to build Dolphin myself.

Regards, Paul

(In reply to comment #4)
> Firstly, I apologise to yourself and the Dolphin team. I was not intending
> to make anyone "feel bad".

OK, understood, thanks!
 
> The point of the rhetorical question, was, I thought, obvious.

Even if you think that some undertone of what you are saying is obvious, please always say it explicitly anyway. Any statements can be misinterpreted very easily otherwise, even more so in a place like bugs.kde.org where everything revolves around the things that people do not like about a product.

> Integrate semantic data by all means, many users I'm sure will use and
> benefit from it, however, there are users who prefer not to.

And they are very much free not to use the semantic data integration, see below.

> Dolphin is user
> configurable to a large extent, choice of previews and services for example.
> I would have thought it would have been a trivial task to have offered an
> option within set-up to, for example: "Use Basic File Information Only" in
> the information panel.

Detecting at runtime if Baloo is installed on the system and then enabling its features in Dolphin if that is the case is currently not possible. In principle, one could implement an approach where everything that Baloo provides is put into a plugin that could be searched and found at runtime, like for the previews and services, but this is *not* trivial. One would have to put an abstract base class for the "semantic data" functionality into a library that both Dolphin and Baloo depend on and make use of this in both packages. If it was just about the Information Panel, this would in principle be possible, but Baloo provides more - the additional information provided by it can also be shown in the views, and implementing all of this in a plugin-based approach would complicate the code immensely. And then the obvious question is: what benefit would the user have if we do that? If everyone is free to disable Baloo, why is it so important to also uninstall it?

> Basic as in the information comes purely from the
> file system - indeed as it did before the introduction of the previously
> nepomuk and now baloo widget.

AFAIK, we have had a Nepomuk-based widget in the Information Panel since KDE 4.0 (it was still part of kdelibs then, but it did use the old Nepomuk 1 library that is part of it). The behavior always was, and still is: If Nepomuk/Baloo is enabled for the respective location (note that *enabled* is very much different from *installed*) and can provide information about the file, show it, if not, just show the info provided by the file system. If you disable Baloo by adding your home folder to its "excluded folders" in System Settings (if you would prefer a "Enable/disable Baloo" checkbox, please do not complain about it here - AFAIK, it is being considered to add such a checkbox), then everything should behave *exactly* like it did in earlier KDE releases if you had Nepumuk disabled.

> As I said, I shall have to learn how to build Dolphin myself.

To be honest, I still do not understand why you want to get rid of the Baloo package on your system so badly. Maybe you could enlighten us? Why is disabling Baloo not sufficient? I assume that you and the "many users" whom you mention just disabled Nepomuk in earlier KDE releases and were happy (at least we never got any report like the present one before Baloo was introduced). Why was disabling Nepomuk a satisfying option, but disabling Baloo isn't? I really do not understand it, sorry.

Thanks for your detailed and informative reply. Please let me briefly elaborate
on a few points.

However, first:

> Even if you think that some undertone of what you are saying is obvious,
> please always say it explicitly anyway.

I fully appreciate the importance of that and would like to offer you a
personal apology. Although no excuse, my frustration with baloo's behaviour
has been increasing over the last few days.


> Detecting at runtime if Baloo is installed...

OK, the task is not as trivial as I assumed. Point taken.


> If it was just about the Information Panel, this would in principle be
> possible, but Baloo provides more...

I was referring *only* to the Information Panel. The "wish request" was after
all against the component "Panels: Information", where I asked that "The
information panels use of semantic data provided by baloo should be made
optional."


> The behavior always was, and still is: If Nepomuk/Baloo is enabled for the
> respective location (note that *enabled* is very much different from
> *installed*) and can provide information about the file, show it, if not,
> just show the info provided by the file system. If you disable Baloo by
> adding your home folder to its "excluded folders" in System Settings (if you
> would prefer a "Enable/disable Baloo" checkbox, please do not complain about
> it here - AFAIK, it is being considered to add such a checkbox), then
> everything should behave *exactly* like it did in earlier KDE releases if
> you had Nepumuk disabled.

That may be the *intended* behaviour, (in which case I would be quite
satisfied), however it is *not* the behaviour I'm seeing.

You know considerably more about Dolphin than I do - this may, probably is due
to a bug in "libbaloowidgets4" (?)

I have, in the relevant sections of baloofilerc, "Indexing-Enabled=false",
"exclude folders[$e]=$HOME/", and "folders[$e]="

With those settings, baloo still gathers "semantic" data, which is stored at
~/.local/share/baloo/file/, comprising an sqlite3 and xapian database. It is 
this which is displayed in Dolphin's Information Panel. Hence the original
"wish".

Temporarily removing the package "baloo-file" prevents data being gathered/
written to the baloo databases. However, Dolphin then does not display *any*
file details in the Information Panel. Therefore, your assertion that "... if
not, just show the info provided by the file system..." appears incorrect.


> To be honest, I still do not understand why you want to get rid of the Baloo
> package on your system so badly. Maybe you could enlighten us?

I have a simple philosophy: An application I want is installed. An application
not wanted is removed.


Regards, Paul

(In reply to comment #6)
> > Even if you think that some undertone of what you are saying is obvious,
> > please always say it explicitly anyway.
>
> I fully appreciate the importance of that and would like to offer you a
> personal apology. Although no excuse, my frustration with baloo's behaviour
> has been increasing over the last few days.

Thanks. The misunderstanding might also be partly my fault - I guess the constant stream of complaints in my inbox, most of which I cannot do anything about, might have made me a bit too sensitive.

> > If it was just about the Information Panel, this would in principle be
> > possible, but Baloo provides more...
>
> I was referring *only* to the Information Panel. The "wish request" was after
> all against the component "Panels: Information", where I asked that "The
> information panels use of semantic data provided by baloo should be made
> optional."

From Dolphin's point of view, the widget that is shown in the Information Panel below the icon/preview image is mostly a black box - we just tell it the current URL and/or which files are selected, and the widget decides what information to show. There is no way to tell the widget "just use data provided by the file system and ignore any semantic data stored in the Baloo database".

> > The behavior always was, and still is: If Nepomuk/Baloo is enabled for the
> > respective location (note that *enabled* is very much different from
> > *installed*) and can provide information about the file, show it, if not,
> > just show the info provided by the file system. If you disable Baloo by
> > adding your home folder to its "excluded folders" in System Settings (if you
> > would prefer a "Enable/disable Baloo" checkbox, please do not complain about
> > it here - AFAIK, it is being considered to add such a checkbox), then
> > everything should behave *exactly* like it did in earlier KDE releases if
> > you had Nepumuk disabled.
>
> That may be the *intended* behaviour, (in which case I would be quite
> satisfied), however it is *not* the behaviour I'm seeing.
>
> You know considerably more about Dolphin than I do - this may, probably is
> due
> to a bug in "libbaloowidgets4" (?)
>
> I have, in the relevant sections of baloofilerc, "Indexing-Enabled=false",
> "exclude folders[$e]=$HOME/", and "folders[$e]="
>
> With those settings, baloo still gathers "semantic" data, which is stored at
> ~/.local/share/baloo/file/, comprising an sqlite3 and xapian database. It is
> this which is displayed in Dolphin's Information Panel. Hence the original
> "wish".

Maybe this is a bug in the Baloo widgets library then.

To my knowledge, the widget in the Information Panel, which is provided by Baloo, should behave just like the Nepomuk widget which was used in Dolphin 4.12 and earlier. As I said, there is basically nothing that Dolphin can do to influence the behavior of the widget, so please report any problems with it for the product "baloo", component "widgets".

> Temporarily removing the package "baloo-file" prevents data being gathered/
> written to the baloo databases. However, Dolphin then does not display *any*
> file details in the Information Panel. Therefore, your assertion that "... if
> not, just show the info provided by the file system..." appears incorrect.

OK, you might be right, but as I said, this is not a Dolphin issue.

> > To be honest, I still do not understand why you want to get rid of the Baloo
> > package on your system so badly. Maybe you could enlighten us?
>
> I have a simple philosophy: An application I want is installed. An
> application
> not wanted is removed.

OK, I understand that. As I said, Dolphin can be built and run just fine without Baloo, and the same applies to most other parts of KDE (one of the few exceptions is KMail, I think).

Building a "Baloo-free" KDE and providing it in an add-on repository to any popular distribution, such that other users can install it, should be quite a straightforward task. Even someone who has never built any code from source can easily find everything that is required by Googling a bit. If there is a single person out there who thinks that doing such a thing is worth the effort, then it will happen at some point.

All understood - Thanks again for your time, informative replies, and patience.

Regards, Paul