search

dalanicolai / gnome-tracker-extension

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

ulauncher 5 patch: Create new 'upgrade' branch to contain py3 main.py file #9

Closed protostork closed 5 years ago

protostork commented 5 years ago

7 Have made some changes to the main.py file to make it compatible with python3, notably:

Have tested this on my local ulauncher 5 install and it seems to work. Haven't tested yet on ulauncher 4, though since the 'upgrade' branch py file is separate from the 'master' branch, this shouldn't cause any issues for backwards compatibility.

dalanicolai commented 5 years ago

@desigit I do not remember exactly why the chmod on appchooser was needed. I remember I had to manually set executable permissions when I pulled the repository from github, so this was my solution to that problem. But I think indeed it is possible to set the executable permissions on the file on github. I still have Ulauncher 4 btw, but I think I will upgrade to 5 now. Because it seems you got everything working there...

dalanicolai commented 5 years ago

Ah... I assumed the 5 version was the official stable version now... but I see that is still version 4... so I will probably wait with upgrading until 5 becomes the official stable version

protostork commented 5 years ago

Thanks and re your earlier thread, no worries about responding quickly :)

Yes, UL 5 beta (and the extension) are working well. It's worth upgrading I think (if you're ok to add their repository) - I haven't had a single crash, and the functionality to run commands without arguments is quite cool, and it seems a bit more memory efficient also...

dalanicolai commented 5 years ago

Thanks for informing me about the upgrade, which I carried out now. The functionality to run commands without arguments seems nice (although I do not see very much the advantage over running a terminal and running some alias. Maybe you have a useful example?).

In addition to my answer on the appchooser script I wanted to mention that I actually implemented the appchooser functionality within ulauncher so that the list of apps are presented in ulauncher itself, and I could get rid of the appchooser script. It was quite some work to figure out how to do it, and of course the advantage was only an aesthetic one. I do not expect you to do anything with it. But if you really get the grips on it and you like to 'pimp' ulauncher or the extension for fun than I just want you to point you to the pull request https://github.com/Ulauncher/Ulauncher/pull/335 (although it was fully functional the guys chose not to merge it because they first wanted to focus on the transition to python 3). Once again I really do not expect you to do anything with it, actually I warn you not to waste your time on it. I only want to make you aware of this attempt as an extra comment on my previous answer, or for the case you really have fun with 'pimping' ulauncher (as I had obviously)

On Fri, 31 May 2019 at 14:27, desigit notifications@github.com wrote:

Thanks and re your earlier thread, no worries about responding quickly :)

Yes, UL 5 beta (and the extension) are working well. It's worth upgrading I think (if you're ok to add their repository) - I haven't had a single crash, and the functionality to run commands without arguments is quite cool, and it seems a bit more memory efficient also...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dalanicolai/gnome-tracker-extension/pull/9?email_source=notifications&email_token=AEMTOXY52S56XJT3QQK2QIDPYEKTZA5CNFSM4HP7YBB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVCRKQ#issuecomment-497690794, or mute the thread https://github.com/notifications/unsubscribe-auth/AEMTOX2LE7ANKGYIZN77SK3PYEKTZANCNFSM4HP7YBBQ .

protostork commented 5 years ago

Oh wow, that's cool - didn't realise that your appchooser.py was a homebrew. Great job, it works very well here. And thanks for the warning - will look into it in more detail some time for fun :).

Regarding the 'commands without arguments' option, I guess it's very much about your workflow and preferences, but I use it primarily to open up static URLs or folders quickly without parameters (or with %s parameters for fast websearches). I was making custom .desktop files before for this for each URL, which was much less elegant.

And yes, it's definitely possible to do the same with terminal & alias, but this is arguably easier to set up and leaves the terminal free for more 'serious' terminal work, plus ULauncher looks prettier and has better UX feedback about keywords :)

dalanicolai commented 5 years ago

@desigit I updated the search method for the gt keyword. It uses a sparql regex filter now instead of tracker's fts:match query option (see here https://wiki.gnome.org/Projects/Tracker/Documentation/Examples/SPARQL/FTS). So I think it uses wildcards now by default in front of and behind the query term. Unfortunately the search is a little slower but the functionality is way more powerful. However it is case sensitive now. I did not yet look up how to make the regex pattern matching case insensitive (anyway the search with the ts keyword is still case insensitive). What do you think? Of course you are welcome to adapt things to your preferences.

Thanks for your suggestion about the static URLS, indeed I agree this is a nice addition. For example I created a .desktop to open the gnome-extensions webpage, so I guess this is a new way to get there quickly.

protostork commented 5 years ago

Nice, thanks for the update, will take a look and test. If it uses standard regex, my tweak to insert between the query_words might break though, since standard regex uses . as it's wildcard.

Regex would definitely be cleaner and easier to maintain than the fts:match. When I have some time, maybe we can change the new 'use wildcards option' in the preferences to instead toggle an 'advanced regex search' mode, which uses the more powerful regex, and a 'simple mode' to just use the previous faster but simpler fts:match search (depends on how much of a performance hit regex searches cause)?

In any case, great job! I had played around with the tracker sparql search specs and I found it quite a difficult system to work with, even with the documentation.

By the way, if you're also on Ulauncher 5 now, how do you think we should maintain the separate UL 4.0 branch and the 5.0 upgrade branch of the codebase? We could port changes to both branches for a while, but it might get cumbersome to maintain in the long run and one branch might not be tested properly if we're both on 5.0. Another option would be to freeze new features on the old version main branch, and just work on the new version?

dalanicolai commented 5 years ago

Hi! I'd like to point out first that I made the regex search case insensitive now. My friend told me that now it finds everything he is looking for (this was not the case before with the fts:match search).

Yes your tweak probably has been broken. But I just outcommented the old search command and put the new command below it... so you can easily revert the change just by uncommenting the old command and outcommenting the new one.

Haha! Yes the sparql documentation is quite elaborate and it is hard to find a concise explanation. I found this https://www.google.com/search?client=firefox-b-d&channel=crow&q=sparql+tutorial#kpvalbx=1 video quite a relief actually. Additionally you can use 'tracker extract filename' to look up the available identifiers. Furthermore I am also far from an expert, I just looked up and copy-pasted enough to make it work.

I was not maintaining the extension anyway. So I suggest we (or you :) ) just maintain the 5.0 upgrade branch. As I do not really use the extension, I prefer to dedicate my time to other things. I only like to add improvements as long as it is a minimal amount of work to help make users happy and productive (and to support gnome and ulauncher by making people enthusiastic about it, incl. tracker). So of course I like your proposal to toggle an advanced regex search mode, but I think I will have no time to work on it. Anyway for now I thought the case-insensitive regex search is the most powerful, and in my opinion therefore the default, search option (although my opinion is worth less than the users opinion, so you decide;)