Re: [Tracker] tracker over activities menu



Hi,

On Tue, Jan 2, 2018 at 1:53 PM, Herr Oswald <herr_oswald gmx de> wrote:
Is it true that the activities menu should call tracker results as well
as tracker-needle? - And in the case - what's going wrong on my
machine?

The current way that GNOME Shell's built-in search facility works is
that different applications each provide search results by
implementing a standard D-Bus API. See
https://developer.gnome.org/SearchProvider/

The search providers are defined by installing files at a certain path
in the system. Here's an example from my laptop (running Fedora 27):


$ ls /usr/share/gnome-shell/search-providers/
gnome-boxes-search-provider.ini
gnome-control-center-search-provider.ini
gnome-terminal-search-provider.ini
nautilus-search-provider.ini
org.gnome.Calculator-search-provider.ini
org.gnome.Calendar.search-provider.ini
org.gnome.Characters.search-provider.ini
org.gnome.clocks.search-provider.ini
org.gnome.Contacts.search-provider.ini
org.gnome.Documents.search-provider.ini
org.gnome.Software-search-provider.ini
org.gnome.Weather.Application.search-provider.ini

When I type in a search term, each of these processes is woken up to
provide search results of different kinds. Some of these do query
Tracker, for example org.gnome.Documents will return any documents
that are known to Tracker and that match the search terms. Others have
no connection with Tracker, for example the Software search provider
returns results from the system's package manager.

The naultilus search provider is the one providing filenames, and it
doesn't currently return anything from the Tracker database. Perhaps
it could do; that would be a feature to discuss with the Nautilus
team. So it sounds like things are working as expected on your system,
even though there might be room for improvement.

Sam

Ps. you might be thinking that waking up 12 processes every time you
type a letter into the Shell's search entry is a bit inefficient, and
you would be correct -- I like the extensible, federated approach of
the current approach but I really don't like the performance
implications.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]