GitLab

This is a mix of store and miner features which can't be assumed to go
together. It is better to leave configuration UI up to the environment,
in the GNOME case this is gnome-control-center search panel.

For settings that fall in the cracks, or for environments that don't
integrate Tracker search in their configuration UI, there's the rather
capable dconf-editor which will provide all toggles, and will explain
them better than any UI we may have.

In the future the CLI tools might gain some configuration subcommand,
but it will not be a graphical UI.

Those are unmaintained, are broken, don't compile, or a combination of
all. Sadly there hasn't been enough manpower during the last years to
keep those up to par. Future seems shiny enough for nautilus, as the
features are being developed in-tree.

If anyone ever remembers there were such plugins and misses them
enough to take over maintainership, by all means reset to the parent
of this commit and take those out of tree. You will have my gratitude.

Thanks too to everyone who ever contributed in those plugins, I'm
not happy to let that much work go.

The only user that might ever care does already implement it itself.
There is no need to provide this infrastructure that will be scarcely
used in libtracker-miner API.

This implementation just pauses the miner while there's writeback
items to process, and uses the filter_event vmethod to perform
maintenance of writeback tasks. Functionally, is not that different
from the TrackerMinerFS implementation.

This is not a signal because external users of a TrackerMiner have no
business in modifying behavior at this level, this is reserved for
subclasses that presumably know what they are doing.

This vmethod is toggled for every event that gets received from the
TrackerFileNotifier, before the file gets to hit any processing queue.

Those were added on autotools, but were forgotten on meson...

It is unneeded, and the missing symbol will be treated as a fatal error.

But warn about it, as it is unsafe.

This can only be used if the default domain ontology file is not found, and
is now used on tests that do rely on the default tracker-store instance.

Also, add back the TRACKER_DB_ONTOLOGIES_DIR, under the same restrictions.

So it can be specified from the miner.

Better than calling the pragma and involving prepared statements

It does not matter much since the getter still returns a sunk reference,
but better to be consistent with the real implementation.

This will make the miners not specified in the domain ontology
description file invisible from the API user perspective.

So it still behaves as it used to do.

This is purely a hint, and people may still run things manually or perform
updates against this domain ontology themselves. Will be useful so we don't
autostart more miners than necessary through the libtracker-control API.

We do already deal with ontology locations at this point, which
we also print.

Pass the TrackerDataManager down tracker_backup_save(), so we can
fetch the DB file underneath.

And exit as soon as the name vanishes. It may safely continue
its operations on the next startup.

And exit as soon as the name vanishes. It may safely continue
its operations on the next startup.

And exit as soon as the name vanishes. It may safely continue
its operations on the next startup.

And exit as soon as the name vanishes. It may safely continue
its operations on the next startup.

Tracker-store will wait till there are no elements left before
exiting, in order to ensure it does so cleanly.

Use the domain name to find out the right tracker-store DBus name.

This should be ported to TrackerNotifier, which already does the right
thing.

Otherwise the database might not be created yet when creating the direct
connection.

I personally prefer using the excuse of the major version bump than adding
a tracker_miner_manager_new_fuller() variant, as this is clearly a
construct_only thing. Creating a TrackerMinerManager with an specific
domain will allow dealing with the miners spawned for it.

These were supposedly added for testing, but they are not used
anywhere, nor it sounds ok to fundamentally change TrackerMinerManager
behavior. Let's remove these.

This will be used by TrackerMinerManager in order to find out
the right dbus names according to the domain ontology.

Because we're registering 2 interfaces and 2 dbus names, both
expose the same 2 interfaces and are introspectable the same way.
This makes no sense, just use the org.freedesktop.Tracker1.Miner.Files
name for both interfaces.

So it is possible to use TrackerMiner facilities in-process using
a dedicated TrackerSparqlConnection. Basically store and mining
handled by the client app.

It must listen to the signal from the right tracker-store instance.

This allows tracker-miner-rss to dump data on other domain ontologies
than the default one.

This allows tracker-extract to dump data on other domain ontologies
than the default one.

This allows tracker-miner-apps to dump data on other domain
ontologies than the default one.

This allows running tracker-miner-fs on other domain ontologies
moderated by a tracker-store daemon. The switch does:
1) Set up the ontology domain for the default TrackerSparqlConnection
2) Make the miner use a DBus name relative to the domain

In result, tracker-miner-fs can take a different DBus name and talk
to other tracker-store instances than the default.

Add a global tracker_sparql_connection_set_domain() call that allows setting
domain ontology that the client shall use. This only affects the connection
obtained through tracker_sparql_connection_get(), other constructors may have
different settings.