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

List:       kde-bugs-dist
Subject:    [Baloo] [Bug 332195] Allow to disable akonadi_baloo_indexer
From:       ash <narutoplasma14 () yahoo ! com>
Date:       2014-08-22 20:53:30
Message-ID: bug-332195-17878-hl5sHFnxBf () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=332195

--- Comment #20 from ash <narutoplasma14@yahoo.com> ---
Just checked in 4.14.0. Akonadi_baloo_indexer processes still running, while
the main checkbox in baloo KCM disabled, and remains like that even after a
reboot

Removing stuff in the Akonadi Resource Configuration KCM does not help, and
when i remove "Local Folders" it respawns immediately

Looks like all the issues since 4.13.1 (remaining after the addition of the
checkbox in Baloo KCM) are still here

__

Please also take a closer look at Bug 331932 referred to at the above comment

The bug was originally asking for the above mentioned checkbox, and so is fixed
as of 4.13.1

But please take a look at comment 8 :

Paolo Palmieri :
"
kdebase-dolphin, kactivities, kdegraphics-gwenview and kdepim-libkdepim are all
dependent on it, so there is no way it can be uninstalled without breaking KDE.
And how can a packager compile dolphin both with and without suport for baloo
in the same package? And even more than that, why would you force dozens of
distro packagers to make efforts for every new KDE release for allowing people
to disable desktop search when you can just let them do so by adding a few
lines of code?
"

This may not be as critical for your typical home or office desktop user, who
generally have the entire KDE SC installed and will suffice with switching off
Baloo if he wishes

However from a software maintenance point of view, it makes simply no point
that Gwenview or Dolphin or PIM won't work without Baloo. The functionality
provided by Baloo is just a minor part of the main functionality of each of
those programs

Imagine Dolphin hard-depending (to the point of not compiling and not starting)
on some minor plugin for the preview of some format of multimedia files. That
would be ridiculous - This functionality is very minor, and with or without it
dolphin is a file manager. Perhaps as a software maintainer i would like to
drop this plugin in order to legally ship a distro in a country with enforced
software patents covering the format of those multimedia files

Same goes for Baloo, it is an extra functionality but logically not crucial. In
the case of Baloo, there may be a myriad other reasons why a software
maintainer would want to ship a distro where, say, Dolphin is installed with
the least possible dependencies

Or me - an IT and i often do custom installations for special purpose systems,
where i just want to have control and avoid potentially troublesome modules for
the purpose i am tailoring the system for

It would make perfect sense if Baloo integration in apps would work according
to this checklist :

For example, i fire up Dolphin, Gwenview or PIM

<1> Detect the presence of installed Baloo, if it is installed, continue to
checklist item <2>, if it is not, just switch off the semantic search features
and do the basic task of managing files, viewing pictures or reading email

<2> If baloo is installed and capable of working, check the user's settings for
Baloo, including not only the self-contained file indexing, but also the user's
settings to enable/disable integration with akonadi or other application

Those 2 items sum up all the showstoppers concerning Baloo IMHO. <1> reduces
dependencies in packages where they dont make sense, <2> enables users complete
control over Baloo's activity, and in a computer shared by few users (while not
being a special-purpose system as in <1>), enables each to configure Baloo
independently

This looks the best way to me to provide options for all existing KDE users set
up everything as they want and ultimately make everyone happy about Baloo

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]