search

dalanicolai / gnome-tracker-extension

Ulauncher extension for (deep) search filesystem via the gnome tracker, recoll, docfetcher, locate or calibre index
63 stars 4 forks source link

Updated gt keyword to use * wildcards in search #3

Closed protostork closed 5 years ago

protostork commented 5 years ago

Fantastic extension, I use it all the time! At the moment, though, the gnome-tracker gt search does not find partial matches for me, but only finds the file if there's a complete match. Have added 4 lines to insert * wildcards into any spaces in the query_words string so that tracker finds also partial matches. Works quite well for me. Would be great if could integrate into main branch if it works for you.

dalanicolai commented 5 years ago

Thanks for your message! And great you take time to share and improve it. Actually I do not use the extension much myself. I helped a friend who wanted this functionality and I thought it is nice practice for me to write this extension. Anyway... because ulauncher only shows a limited number of results I wanted to restrict the number of results from tracker, so personally I prefer to keep the code like this. However, indeed the option of wildcards are quite essential, but they can be added manually in ulauncher just by typing the * (the wildcard only works behind the query term not in front). I did not document this at all, and it is very nice you point this out. So I propose to update the documentation about the option of using wildcards. What do you think? Should wildcards be the default or is it better to leave them optional? If you think default wildcards are a better choice than let me know please (with some motivation).

I wrote another little python script to use tracker for full text searching the file system with tracker, but it also adds options to list or sort on specific properties, or search only in a specific directory. You can find the script here... just place it in your /usr/bin or /usr/local/bin directory and run 'st -h' for help. It might be useful for you too. You can find the script here https://gitlab.com/dalanicolai/tracker_search_tool/tree/master.

Thanks

Best regards Daniel

On Tue, 21 May 2019 at 08:09, desigit notifications@github.com wrote:

Fantastic extension, I use it all the time! At the moment, though, the gnome-tracker gt search does not find partial matches for me, but only finds the file if there's a complete match. Have added 4 lines to insert * wildcards into any spaces in the query_words string so that tracker finds also partial matches. Works quite well for me. Would be great if could integrate into main branch if it works for you.

You can view, comment on, or merge this pull request online at:

https://github.com/dalanicolai/gnome-tracker-extension/pull/3 Commit Summary

  • Updated gt keyword to use * wildcards in search

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX5T72NG246B3JBWZMDPWOG3LA5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GU4A2XA, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOXZJPMTBAEROTDNP75TPWOG3LANCNFSM4HOHU4HA .

dalanicolai commented 5 years ago

Actually I see now I already documented it under "USAGE" on the GitHub page... but I will try to emphasize it somehow

On Wed, 22 May 2019 at 13:57, dalanicolai dalanicolai@gmail.com wrote:

Thanks for your message! And great you take time to share and improve it. Actually I do not use the extension much myself. I helped a friend who wanted this functionality and I thought it is nice practice for me to write this extension. Anyway... because ulauncher only shows a limited number of results I wanted to restrict the number of results from tracker, so personally I prefer to keep the code like this. However, indeed the option of wildcards are quite essential, but they can be added manually in ulauncher just by typing the * (the wildcard only works behind the query term not in front). I did not document this at all, and it is very nice you point this out. So I propose to update the documentation about the option of using wildcards. What do you think? Should wildcards be the default or is it better to leave them optional? If you think default wildcards are a better choice than let me know please (with some motivation).

I wrote another little python script to use tracker for full text searching the file system with tracker, but it also adds options to list or sort on specific properties, or search only in a specific directory. You can find the script here... just place it in your /usr/bin or /usr/local/bin directory and run 'st -h' for help. It might be useful for you too. You can find the script here https://gitlab.com/dalanicolai/tracker_search_tool/tree/master.

Thanks

Best regards Daniel

On Tue, 21 May 2019 at 08:09, desigit notifications@github.com wrote:

Fantastic extension, I use it all the time! At the moment, though, the gnome-tracker gt search does not find partial matches for me, but only finds the file if there's a complete match. Have added 4 lines to insert * wildcards into any spaces in the query_words string so that tracker finds also partial matches. Works quite well for me. Would be great if could integrate into main branch if it works for you.

You can view, comment on, or merge this pull request online at:

https://github.com/dalanicolai/gnome-tracker-extension/pull/3 Commit Summary

  • Updated gt keyword to use * wildcards in search

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX5T72NG246B3JBWZMDPWOG3LA5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GU4A2XA, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOXZJPMTBAEROTDNP75TPWOG3LANCNFSM4HOHU4HA .

protostork commented 5 years ago

Hi Daniel, great to hear from you!

Agree, wildcards can also be used manually. Though, since requested, I would argue a space is always easier to hit than an asterisk when quickly looking for a file, particularly for newbies (I may also be a bit biased, since I migrated to ulauncher from Launchy, which had quite fast file name search capability that would search with spaces as the wildcard. Also, the same auto-wildcard behaviour is standard for MS Windows Everything search or Nautilus' file search, for instance, so it could be expected behaviour from users).

In any case, it's your call of course - the version of gnome-tracker I'm using locally is quite heavily modified anyway, and I don't want to add to your workload if you're not actively maintaining this (though it surely deserves to be far more popular than it currently is, considering how useful it is!).

Happy to file a few more feature / bug requests if interested, though no pressure to implement of course.

Ps: Thanks for sharing the tracker_search_tool script, that looks really useful for powersearching the tracker store, look forward to using it! :+1:

protostork commented 5 years ago

One thing I hadn't considered is that if you were to patch gnome search like this, then something similar might have to be done with the locate, docfetcher and tracker search options (otherwise users may be confused why it's not behaving the same with the other keywords).

I had locally modified 'locate' to include wildcards by default, but haven't used docfetcher. In case, you think it's potentially a good idea, I would be happy to do another pull request some time to integrate those.

dalanicolai commented 5 years ago

I do not remember well but I think the space used to function as the AND operator. Does your script preserves this functionality?

On Wed, 22 May 2019 at 14:11, desigit notifications@github.com wrote:

Hi Daniel, great to hear from you!

Agree, wildcards can also be used manually. Though, since requested, I would argue a space is always easier to hit than an asterisk when quickly looking for a file, particularly for newbies (I may also be a bit biased, since I migrated to ulauncher from Launchy, which had quite fast file name search capability that would search with spaces as the wildcard. Also, the same auto-wildcard behaviour is standard for MS Windows Everything search or Nautilus' file search, for instance, so it could be expected behaviour from users).

In any case, it's your call of course - the version of gnome-tracker I'm using locally is quite heavily modified anyway, and I don't want to add to your workload if you're not actively maintaining this (though it surely deserves to be far more popular than it currently is, considering how useful it is!).

Happy to file a few more feature / bug requests if interested, though no pressure to implement of course.

Ps: Thanks for sharing the tracker_search_tool script, that looks really useful for powersearching the tracker store, look forward to using it! 👍

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX2L2HYLZR7ZXLRQFO3PWU2A7A5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV625ZQ#issuecomment-494776038, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOX4CNCV3AKY3SH7B3N3PWU2A7ANCNFSM4HOHU4HA .

dalanicolai commented 5 years ago

Well... I found annoying that often I got so many results from locate that ulauncher became useless. So now I prefer to use locate from the command line in combination with pmenu

On Wed, 22 May 2019 at 14:25, desigit notifications@github.com wrote:

One thing I hadn't considered is that if you were to patch gnome search like this, then something similar might have to be done with the locate, docfetcher and tracker search options (otherwise users may be confused why it's not behaving the same with the other keywords).

I had locally modified 'locate' to include wildcards by default, but haven't used docfetcher. In case, you think it's potentially a good idea, I would be happy to do another pull request some time to integrate those.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX7OY62PNWGJUDFXNFDPWU3SHA5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV634XY#issuecomment-494779999, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOX3CHQT2BVQ4WN4I2ETPWU3SHANCNFSM4HOHU4HA .

dalanicolai commented 5 years ago

For example that is the reason why I made the locate command also case sensitive. And I remember I wrote somewhere that users could change the code locally to include the -i option if they wanted case insensitive behavior.

On Wed, 22 May 2019 at 14:37, dalanicolai dalanicolai@gmail.com wrote:

Well... I found annoying that often I got so many results from locate that ulauncher became useless. So now I prefer to use locate from the command line in combination with pmenu

On Wed, 22 May 2019 at 14:25, desigit notifications@github.com wrote:

One thing I hadn't considered is that if you were to patch gnome search like this, then something similar might have to be done with the locate, docfetcher and tracker search options (otherwise users may be confused why it's not behaving the same with the other keywords).

I had locally modified 'locate' to include wildcards by default, but haven't used docfetcher. In case, you think it's potentially a good idea, I would be happy to do another pull request some time to integrate those.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX7OY62PNWGJUDFXNFDPWU3SHA5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV634XY#issuecomment-494779999, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOX3CHQT2BVQ4WN4I2ETPWU3SHANCNFSM4HOHU4HA .

dalanicolai commented 5 years ago

I am indeed quite busy with other things and not actively maintaining this project. But it is great if you want to improve things. So I propose that either you fork this repository, or I make you collaborator on this repository and you can add improvements yourself. Of course I am always willing to discuss with you before you make any decisions, as I am doing now. What do you think?

On Wed, 22 May 2019 at 14:40, dalanicolai dalanicolai@gmail.com wrote:

For example that is the reason why I made the locate command also case sensitive. And I remember I wrote somewhere that users could change the code locally to include the -i option if they wanted case insensitive behavior.

On Wed, 22 May 2019 at 14:37, dalanicolai dalanicolai@gmail.com wrote:

Well... I found annoying that often I got so many results from locate that ulauncher became useless. So now I prefer to use locate from the command line in combination with pmenu

On Wed, 22 May 2019 at 14:25, desigit notifications@github.com wrote:

One thing I hadn't considered is that if you were to patch gnome search like this, then something similar might have to be done with the locate, docfetcher and tracker search options (otherwise users may be confused why it's not behaving the same with the other keywords).

I had locally modified 'locate' to include wildcards by default, but haven't used docfetcher. In case, you think it's potentially a good idea, I would be happy to do another pull request some time to integrate those.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/3?email_source=notifications&email_token=AEMTOX7OY62PNWGJUDFXNFDPWU3SHA5CNFSM4HOHU4HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV634XY#issuecomment-494779999, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOX3CHQT2BVQ4WN4I2ETPWU3SHANCNFSM4HOHU4HA .

protostork commented 5 years ago

Thanks for considering Daniel! You're probably right regarding 'locate' producing too many results. However, tracker sorts by last accessed by default, so I've found that the most relevant results usually bubble to the top (and I think tracker defaults to AND). But I also restricted tracker to stay away from some directories to try and speed up the daemon a bit, so your mileage may vary, depending on your filesystem and what you're searching for.

Thanks very much for the offer of being a collaborator. Though I don't feel I have enough github experience yet to take that responsibility. But I'd love to do what you suggest and make a fork and work on that a bit when I have some time and loop back to you to discuss any additions.

dalanicolai commented 5 years ago

I am still not sure about using the wildcard by default. Because people might expect the wildcards work in front of the query too. So at least I updated the documentation (i.e. readme file). Does not locate implicitly use wildcards?

protostork commented 5 years ago

Will close this pull request since superseded by latest optional wildcards search.