(In reply to comment #0)
> Tracker doesn't need the files miner to be on the present to be useful or work.
> However, if the files miner is not there, most of the tabs in
> tracker-preferences don't make any sense. They should just get hidden in such a
> case.

The miner-fs can not be disabled at all (in terms of not installing/building it), it can be disabled by config, so right now it doesn't make sense to update the preferences like this I would say.

The preferences are quite hard to get right here, since they should sum up what's important for the user across ALL miners and the store. This requires some plugin infrastructure potentially and we don't have that yet. So it is a bit lacking here.

(In reply to comment #1)
> (In reply to comment #0)
> > Tracker doesn't need the files miner to be on the present to be useful or work.
> > However, if the files miner is not there, most of the tabs in
> > tracker-preferences don't make any sense. They should just get hidden in such a
> > case.
> 
> The miner-fs can not be disabled at all (in terms of not installing/building
> it),

Err, isn't this a decision the packagers can take? :-) I'm splitting miner-fs in a subpackage in openSUSE right now. If it's completely wrong to do so, then I won't, but I see no reason to not do it. (it would still be installed by default, but it's more flexible this way)

(In reply to comment #2)
> Err, isn't this a decision the packagers can take? :-) I'm splitting miner-fs
> in a subpackage in openSUSE right now. If it's completely wrong to do so, then
> I won't, but I see no reason to not do it. (it would still be installed by
> default, but it's more flexible this way)

It is potentially possible, but we haven't actually added any configure switch or put in place any work to make this happen from a build point of view. You can of course install the miner and disable it from starting on start up and/or set the config so it never crawls, etc. But not installing it at all is something that's not been allowed for yet. However, it should still be possible. The properties dialog is exactly what I mean here when I say, not been allowed for.

(In reply to comment #3)
> (In reply to comment #2)
> > Err, isn't this a decision the packagers can take? :-) I'm splitting miner-fs
> > in a subpackage in openSUSE right now. If it's completely wrong to do so, then
> > I won't, but I see no reason to not do it. (it would still be installed by
> > default, but it's more flexible this way)
> 
> It is potentially possible, but we haven't actually added any configure switch
> or put in place any work to make this happen from a build point of view. You
> can of course install the miner and disable it from starting on start up and/or
> set the config so it never crawls, etc.

The thing I see here is that:

 - either miner-fs is always installed and the decision of enabling it by default is up to the packager (an administrator could arguably tweak the autostart file, though)

 - or there's an option to not install miner-fs and the decision to have file indexing is done when selecting the packages to install. This makes it easily possible to disable file indexing for the admin but also for people building a distro using those packages

I'd agree that it doesn't affect most people, though.

> But not installing it at all is
> something that's not been allowed for yet. However, it should still be
> possible. The properties dialog is exactly what I mean here when I say, not
> been allowed for.

Nod. I think people can live with this for now, and I'll keep miner-fs in a separate package. Would be nice to fix the properties dialog in the future.

I might take a look if I find some time... I would guess we can simply hide some widgets/tabs depending on the existence of, say, /usr/share/tracker/miners/tracker-miner-files.desktop (since I don't think we can rely on the fact that's it's running and on dbus).

(In reply to comment #4)
> The thing I see here is that:
> 
>  - either miner-fs is always installed and the decision of enabling it by
> default is up to the packager (an administrator could arguably tweak the
> autostart file, though)

Currently, we consider the miner-fs as something that should always be installed because without it, the store is quite useless (unless you have 3rd party apps populating it which isn't the case for the majority of situations right now).

>  - or there's an option to not install miner-fs and the decision to have file
> indexing is done when selecting the packages to install. This makes it easily
> possible to disable file indexing for the admin but also for people building a
> distro using those packages

There is currently a switch in configure to disable all other miners right now, we can add one for the miner-fs, but as I said, I am reluctant, because without it, the store is just an empty database with no reason to be there - unless you know of apps populating it?
 
> I'd agree that it doesn't affect most people, though.
> 
> > But not installing it at all is
> > something that's not been allowed for yet. However, it should still be
> > possible. The properties dialog is exactly what I mean here when I say, not
> > been allowed for.
> 
> Nod. I think people can live with this for now, and I'll keep miner-fs in a
> separate package. Would be nice to fix the properties dialog in the future.

I agree, it is something I have been meaning to fix for the other miners too - they too shouldn't have their options in the dialog if they're never installed. A general plugin/config system is needed here for this.
 
> I might take a look if I find some time... I would guess we can simply hide
> some widgets/tabs depending on the existence of, say,
> /usr/share/tracker/miners/tracker-miner-files.desktop (since I don't think we
> can rely on the fact that's it's running and on dbus).

Sorry, not sure what you meant there by relying on it running/on dbus?

(In reply to comment #5)
> Sorry, not sure what you meant there by relying on it running/on dbus?

I meant something like "looking for org.freedesktop.Tracker1.Miner.Files", I guess :-)

The final goal is that distribution maintainers can decide what combination of miners suits them better. Some miners will be in the tracker source code tree, some will come from third party projects. 

Right now you will always compile the filesystem miner (because we don't have an option in autotools to disable its compilation) and at packaging time you can put it in its own package (which makes complete sense).

Probably the miners should provide also their "configuration tab" for the preferences dialog... So this bug should be something like "preference dialog should support plugins"

I am just going to rename this bug, since it is really about disabling miner-fs

(In reply to comment #8)
> I am just going to rename this bug, since it is really about disabling miner-fs

It's not: I want to build miner-fs (since it will be in a package). It's just the UI that needs to reflect the existence of miner-fs on the system.

(In reply to comment #9)
> (In reply to comment #8)
> > I am just going to rename this bug, since it is really about disabling miner-fs
> 
> It's not: I want to build miner-fs (since it will be in a package). It's just
> the UI that needs to reflect the existence of miner-fs on the system.

Well, if the miner-fs is not on the system, it is the same problem, the preferences needs to be able to deal with that. I just made this bug encompass more issues generally related to disabling the fs miner.

Marking as FIXED, this option has been around for a while, I just forgot to mark the bug as fixed!