[recoll-user] Re: Any interest in a Google Chrome browser plugin?

  • From: Jean-Francois Dockes <jfd@xxxxxxxxxx>
  • To: recoll-user@xxxxxxxxxxxxx
  • Date: Sun, 18 Apr 2021 17:16:49 +0200

David King writes:

I have not found a recoll web caching plug-in for Google Chrome? Is 
there one?  Are there plans to develop one?

I think that I gave a try to running the Firefox extension in Chrome after the 
initial
conversion from the old Firefox API, and it almost ran but not quite, and I did
not try after the most recent changes. There is nothing else as far as I know.

I've done a proof-of-concept for my own use by modifying the existing 
Firefox plugin to make it work in Chrome.

What I've got right now is definitely not ready for prime time. I'm 
curious if there is any interest in polishing up and integrating in what 
I've done?  It's not standalone, it would have to be integrated into the 
code that JF supports.

I think that it would be nice to have a Chrome version of the plugin. There are
not many users of the Firefox extension, but some of them swear by it, and of
course there are many more Chrome or Chromium users theses days.

The code I've added uses a small, local web service running in the 
Python Flask framework which accepts requests from the browser plugin 
and writes the recoll webcache files out to their target directory.  I 
did it this way because I was unable to get the Chrome version of the 
downloads.download method used in the plugin to reliably set the 
filename of the downloaded file.  Chrome has a 
downloads.onDeterminingFilename listener that any plugin can instantiate 
which can and will modify the filename used in all browser file 
downloads.  I couldn't find a reliable method to prevent the listener 
defined in the "Aria2c Integration" plugin I have installed, for 
example, from changing the filenames of my recoll-we plugin download 
files.  A secondary factor was that, while I like to use the downloads 
bar in the browser, I don't like having two recoll downloads show up 
there every time I visit a web page.  Using a local web service as I did 
avoided these problems. On the other hand, adding a web service to this 
process adds yet another level of complexity.  Fine for somebody like 
me, not so good for a user who expects it all to "just work."

Yes, having a separate process running does seem a bit over the top for
this. The script which moves the file to the Recoll queue could be adapted for
any workable naming scheme if you can work one up.

I couldn't register on opensourceproject.eu so I couldn't fork JF's 
recoll-we code there.  Even tried VPNing to an EU IP address but I kept 
getting 500 errors no matter where I came from.  So, I've put my version 
of the plugin on github, at https://github.com/dlk3/recoll-we-chrome.  ;
My mods are in the background.js and the new recoll-we-webservice.py 
scripts.

opensourceprojects.eu is dead, and the code there is quite a bit behind the
current code for the extension which is here:
https://framagit.org/medoc92/recoll-we

I'm not sure how far off is the code you started from open opensourceprojects,
this would be the first thing to check.

I'd delete the opensourceprojects repositories, but I can't even log in to the
site any more...

Cheers,

jf

Other related posts: