@gurdas new home of the add-on here: https://adam3smith.github.io/zotero-prevent-duplicates/ I've run one test with the copy there and it works, but you'll understand that I won't have much (if any) time to maintain that if it breaks. I will accept PRs though and resign the add-on as needed.
Thank you very much, @adamsmith. Works as expected. Could you please add 'Homepage' field to the description that pops up on clicking 'More' in 'about:addons'?
I'll not put out new releases for cosmetics, sorry (so no homepage in about:addons unless I'm making other changes.) PRs are pull requests, it's how people can contribute to open source projects https://help.github.com/articles/about-pull-requests/
certainly not in 5.0, no. I'd love to have this -- if I didn't think it was worthwhile I wouldn't have bothered getting the add-on signed. But it's fairly involved making this happen properly, so I wouldn't expect it super soon.
I'd also say that making the add-on work with Zotero 5.0 might not be a great investment since it's fairly likely that Zotero will switch to a Standalone-only model some time in the not-so-distant future, and the add-on as it works now wouldn't work anyway.
"I'd also say that making the add-on work with Zotero 5.0 might not be a great investment since it's fairly likely that Zotero will switch to a Standalone-only model some time in the not-so-distant future, and the add-on as it works now wouldn't work anyway."
That is certainly worth knowing as a "future direction", so any future ideas for 3rd party tools and features should focus on Zotero 5.0 stand alone?
I'm experimenting with some ideas I have for add-on features and today I am just extending the note editor panel. i.e. expanding zotero.jar and hacking its resources/tinymce contents.
Are there any tutorials to help developers create add-on tools to be recognised by Zotero 5.0 as "plugins".
For the most part, there is very little difference in developing add-ons for Standalone and for Firefox. E.g. anything like what you're doing will just need to include the relevant app compatibility statement in install.rdf and will just work in Standalone. You can check any of the existing apps or Zotero's Hello World! one for an example.
Prevent Duplicates is different because it interacts directly with item saving (which is partly handled in the connectors for Standalone).
Interacting with 5.0 is quite a bit different for apps, so at this point you definitely want to be working with Zotero beta rather than the 4.0.29.x version. There is at least one thread with info on this on zotero-dev.
@dragonfly, and even the days of the current XUL-based plugins for Zotero Standalone are numbered, since it's been announced that the next big version after Zotero 5.0 will use a very different foundation (Electron, instead of Firefox/XUL).
@adamsmith Would it be possible to have a minimum viable product version of the prevent duplicates feature built-in for Zotero 5.0 or 5.0.1? I was thinking something that checks ONLY the DOI and pops a dialog if there is a match. Just that will take care of most journal article duplicate addition.
the difficulty is not the matching algorithm (which could just be copied from the current add-on) but the technology for "intercepting" the duplicates before they're written to the database. It's obviously possible to do; it's a good feature to have, but so are dozens of others and someone has to do it. You've made very clear how important this is to you, at this point you'll either have to do it yourself or wait.
Well, it might be hard developing plugins for Electron-based Zotero right now as there isn't yet a development version of Electron-based Zotero available :). My main point was that it might not be worth spending months developing XUL plugins for Zotero if the XUL-version of Zotero is going to be deprecated in a year or two.
@Rintze, I don't have in mind developing Electron based plugins (at least not yet) but instead breaking into (hacking) the existing zotero.jar structure. i.e. a hybrid of existing Zotero + Electron. That is the theory. I'll let you know later if it works.
Still not sure what Electron has to do with this — as Rintze says, there's no Electron-based Zotero right now.
But whatever you're doing, "hacking" zotero.jar is almost certainly not the right approach. If you want to make code changes to Zotero and don't want to do it as a plugin, it's much better to just modify a git checkout of the source and either run from that (Firefox) or build a new XPI (Firefox/Standalone):
This may not be the appropriate thread to discuss this but as I explained I have been testing out some ideas by just unpacking zotero.jar and hacking notes editor (as a convenient entry into Zotero). I found this to be a very quick method for testing ideas by adding code in /resources folder.
For example I was able to get TinyMCE 4.4.3 working (coexisting with default version 3.5.7) and added iframe, js and SVG to tinymce valid_elements.
One aim I have is to harness SVG to map relations between Zotero nodes.
Another aim is to add more granular annotation to the PDF annotations which come from ZotFile (which currently loses the colour dimension in annotations).
For these extensions I could (although not necessarily) adopt Electron, just to gain experience in its use. But I agree that Electron is a red herring at the moment.
However, I decided to follow your advice to abandon my “hacking” approach and instead try to build Zotero Stand Alone. I referred to the link you provided ...
Building Zotero_linux-i686 cp: cannot stat ‘~/zotero_build/zotero-standalone-build/xulrunner/firefox-i686/!(application.ini|browser|defaults|crashreporter|crashreporter.ini|firefox-bin|precomplete|removed-files|run-mozilla.sh|update-settings.ini|updater|updater.ini)’: No such file or directory
And looking in ~/zotero_build/zotero-standalone-build/staging I see Zotero_linux-i686 .. but it is empty. What build step have I missed?
[Later Edit] Inspecting xulrunner further ... ~/zotero_build/zotero-standalone-build/xulrunner/firefox-i686/ is not seen .. instead I have ... ~/zotero_build/zotero-standalone-build/xulrunner/Firefox%2049.0b10.dmg .. size 81.3 MB ...
[Finally Solved] (a) The Firefox.dmg file arose from my first efforts where I failed to place the three created zotero folders into one common folder. In fact Firefox.dmg was a Mac file and I deleted it to start afresh.
(b) The command ./fetch_xulrunner.sh -p m .. in fact had to be ./fetch_xulrunner.sh -p l to choose a Linux installation (the m argument). Somehow, in my earlier efforts, a Mac installation was selected (hence the *.dmg file being created in xulrunner). But Linux Stand Alone has now been built to completion.
For these extensions I could (although not necessarily) adopt Electron, just to gain experience in its use.
This is what I think you're misunderstanding. Electron is an application platform. It has no relation to Zotero until we rebuild Zotero on top of it, so it has no relevance to any plugins you would create for Zotero at this time. Maybe you're thinking of React? (We'll be using React in the Electron rebuild, but one doesn't depend on the other.)
not going to happen, as I think I've said before. Given that PD never worked in Standalone, this would require effectively a complete re-write, which is not something I'll be able to do. I think there is a very good case to be made for the functionality in Zotero proper, alas that's also the case for lots of other things.
I've run one test with the copy there and it works, but you'll understand that I won't have much (if any) time to maintain that if it breaks. I will accept PRs though and resign the add-on as needed.
And what is PR?
https://help.github.com/articles/about-pull-requests/
I'd also say that making the add-on work with Zotero 5.0 might not be a great investment since it's fairly likely that Zotero will switch to a Standalone-only model some time in the not-so-distant future, and the add-on as it works now wouldn't work anyway.
"I'd also say that making the add-on work with Zotero 5.0 might not be a great investment since it's fairly likely that Zotero will switch to a Standalone-only model some time in the not-so-distant future, and the add-on as it works now wouldn't work anyway."
That is certainly worth knowing as a "future direction", so any future ideas for 3rd party tools and features should focus on Zotero 5.0 stand alone?
I'm experimenting with some ideas I have for add-on features and today I am just extending the note editor panel. i.e. expanding zotero.jar and hacking its resources/tinymce contents.
Are there any tutorials to help developers create add-on tools to be recognised by Zotero 5.0 as "plugins".
I found this for building stand alone ...
https://www.zotero.org/support/dev/client_coding/building_the_standalone_client
Prevent Duplicates is different because it interacts directly with item saving (which is partly handled in the connectors for Standalone).
Interacting with 5.0 is quite a bit different for apps, so at this point you definitely want to be working with Zotero beta rather than the 4.0.29.x version. There is at least one thread with info on this on zotero-dev.
Further reading unearthed this explanation of deprecation ...
https://github.com/willsALMANJ/Zoterodactyl
https://groups.google.com/forum/#!topic/zotero-dev/yy4-q_ZUA4M
So all roads now lead to stand alone.
It's obviously possible to do; it's a good feature to have, but so are dozens of others and someone has to do it. You've made very clear how important this is to you, at this point you'll either have to do it yourself or wait.
i.e. a hybrid of existing Zotero + Electron.
That is the theory. I'll let you know later if it works.
But whatever you're doing, "hacking" zotero.jar is almost certainly not the right approach. If you want to make code changes to Zotero and don't want to do it as a plugin, it's much better to just modify a git checkout of the source and either run from that (Firefox) or build a new XPI (Firefox/Standalone):
https://www.zotero.org/support/dev/source_code#running_git_installations
This may not be the appropriate thread to discuss this but as I explained I have been testing out some ideas by just unpacking zotero.jar and hacking notes editor (as a convenient entry into Zotero). I found this to be a very quick method for testing ideas by adding code in /resources folder.
For example I was able to get TinyMCE 4.4.3 working (coexisting with default version 3.5.7) and added iframe, js and SVG to tinymce valid_elements.
One aim I have is to harness SVG to map relations between Zotero nodes.
Another aim is to add more granular annotation to the PDF annotations which come from ZotFile (which currently loses the colour dimension in annotations).
For these extensions I could (although not necessarily) adopt Electron, just to gain experience in its use. But I agree that Electron is a red herring at the moment.
However, I decided to follow your advice to abandon my “hacking” approach and instead try to build Zotero Stand Alone. I referred to the link you provided ...
https://www.zotero.org/support/dev/source_code#running_git_installations
Although this is not explicitly explained in the instructions I read, I found that I had to place all sub-folders into a common folder.
~/zotero_build/zotero
~/zotero_build/zotero-build
~/zotero_build/zotero-standalone-build
In the final step running ./dir_build in ~/zotero_build/zotero-standalone-build/scripts
I saw this error at end of terminal ...
zotero-build.xpi and update-build.rdf saved to ~/zotero_build/zotero-build/xpi/build
Building from ~/zotero_build/zotero-build/xpi/build/zotero-build.xpi
Version: 5.0.SOURCE.8208ece
Channel: pref("app.update.channel", "source");
Building Zotero_linux-i686
cp: cannot stat ‘~/zotero_build/zotero-standalone-build/xulrunner/firefox-i686/!(application.ini|browser|defaults|crashreporter|crashreporter.ini|firefox-bin|precomplete|removed-files|run-mozilla.sh|update-settings.ini|updater|updater.ini)’: No such file or directory
And looking in ~/zotero_build/zotero-standalone-build/staging
I see Zotero_linux-i686 .. but it is empty.
What build step have I missed?
===========================================================
[Later Edit]
Inspecting xulrunner further ...
~/zotero_build/zotero-standalone-build/xulrunner/firefox-i686/
is not seen .. instead I have ...
~/zotero_build/zotero-standalone-build/xulrunner/Firefox%2049.0b10.dmg .. size 81.3 MB
...
[Finally Solved]
(a) The Firefox.dmg file arose from my first efforts where I failed to place the three created zotero folders into one common folder. In fact Firefox.dmg was a Mac file and I deleted it to start afresh.
(b) The command ./fetch_xulrunner.sh -p m .. in fact had to be ./fetch_xulrunner.sh -p l
to choose a Linux installation (the m argument). Somehow, in my earlier efforts, a Mac installation was selected (hence the *.dmg file being created in xulrunner). But Linux Stand Alone has now been built to completion.
===========================================================
I think there is a very good case to be made for the functionality in Zotero proper, alas that's also the case for lots of other things.