Incompatible with Gnome 3.18

hamiller / tracker-search-provider

Gnome-shell extension: displays tracker search results in the shell overview

16 stars 13 forks source link

Incompatible with Gnome 3.18 #17

Closed arigit closed 8 years ago

arigit commented 8 years ago

The extension shows as "outdated" in extensions.gnome.org and won't install This is on Fedora 23

ikuraj commented 8 years ago

Any hopes for updating to 3.18?

hamiller commented 8 years ago

Definitely, but I've got currently not the time to test it. If you wish, you could try it by yourself:

Check out the tree https://github.com/hamiller/tracker-search-provider/tree/gnome_16
Edit metadata.json by changing "3.16" to "3.18"
Copy directory to ~/.local/share/gnome-shell/extensions/
Reload gnome-shell

ikuraj commented 8 years ago

Seems to be working fine here... (Testing it by sporadically while using it for a few days.)

ikuraj commented 8 years ago

One thing that is annoying and not sure why it is happening is that it seems to be that the extension searches some directories by default (e.g. /usr/share/applications/). Interestingly, if I try the same query within tracker, I don't get those results (and this is okay, since that dir does not belong to the set of tracked directories). Any ideas?

hamiller commented 8 years ago

i don't think this is an issue of the extension: it's just a frontend for tracker and doesn't index anything itself. you can look in the source in check the query it uses. also be aware some data from /usr/share/applications could actually be from ./local/share/applications.

ikuraj commented 8 years ago

But the inconsistency of the results from the same query from two different ways of invoking it seems suspicious already. Should this be reported upstream?

Trim commented 8 years ago

Hello,

Sorry for the late answer. First, thanks for the test of 3.18 compatibility. Then, about your second question:

If I try the same query within tracker

I'm not surprised that results are different, we certainly don't apply same filters on the SPARQL query.

For me this an issue of tracker configuration: if you don't want to see all files from your $HOME, you should configure tracker to not scan your $HOME directory, but only your $HOME/Documents for example.

ikuraj commented 8 years ago

I don't think my tracker configuration is set to scan home or /usr dir. Here is the output from gsettings list-recursively | grep -i org.freedesktop.Tracker | sort | uniq:

1150:org.freedesktop.Tracker.Miner.Files index-recursive-directories ['/home/user/resources/indexed']
1160:org.freedesktop.Tracker.Miner.Files index-single-directories ['/home/user/resources', '&DOCUMENTS']

That is why I think the issue is in the extension (possibly in the SPARQL query).