4.2 Comments on filelinks

Help
1

I downloaded 4.2 to try out, and the file link feature still does not work properly. In jabref 3 if I click “get fulltext” it immediately links to my files on my hard-drive. On 4.2 with the same bibtex file - it croaks and I have to manually shut jabref down (same problem in Jabref 4.1 which I report ages ago).

So I am back to jabref 3 until this is fixed - my workflow entails getting hard copies of papers I am working on and linking them to my bibtex. Jabref 3 is very good- jabref 4 at the moment is still not ready for researchers who have large bibtex files.

I am running this on opensuse 42.2 with java 8.

Many thanks in advance.

2

Hi

you could try to change to another Look and Feel in the Settings in JabRef 4. Try metal, instead of GTK.
GTK Style is known to be problematic.

3

I have downloaded the latest build.

I have local copies of important papers on my file system (a few thousand) and on jabref 3 when open general, and search file links, it finds the file with the correspond Bibtex key in less than a second.

On the recent version of jabref, when I click search it ignores the local file, and spends 30 seconds or so searching on the web and then downloading a file I already have on my disk.

There must be a way to stop this ? Jabref 3 is perfect, so I am not sure why the team as decided to make this feature worst?

Until this is fixed, I cannot switch to jabref 4. It is much less efficient that jabref 3 (and I have noticed other researchers have made the same point). Jabref 3 is such a terrific product - I worry that the poor performance of jabref 4 will undermine its use?

Thanks so much. wbm

4

Hi,

Look up Fulltext always performs a web search and downloads the paper, if found.
What you want is “Quality -> Autolink files”
Since version 4 JabRef has an autolink feature which also triggers automatically when you open the General Tab of an entry. With a click you can simply set the auto-found document

And make sure you use the latest java 8 version (172) .

Regarding the performance. Since version 4 we constantly have worked on performance improvements and really fixed a lot of issues regarding this.

Please keep in mind that all devs here are working in their free-time on the software and that we do not earn anything from our work at JabRef. There’s not big company behind JabRef.
However, as JabRef is OpenSource you are able to contribute to JabRef’s development in many forms, even if you’re not a programmer:
https://help.jabref.org/en/FAQcontributing

See this issue for a discussion

5

Dear Christoph.

Thanks so very much for the reply. I realize and appreciate the work - I am trying to help by giving feedback from a person that is an actual researcher who uses bibtex intensively - I would help with dev, but currently stuggling to keep up with my coding in R and Julia and python - no time to add java…

I suspect my view represent may users. Some points:

.1. Jabref 3 is very very good - one think I like about it is that it is setup to deal with a large data base efficiently - I have over 5000 citations and papers and add 5-10 papers every day. I would have preferred refinement of jabref 3 and moving it to java 9/10/

  1. Our libary recommends mendaly and zotero - I get the sense you trying to match them? Couple of points. With the problems I faced with jabref 4 I tried to swich to these, but they are simply “too automated” and they are really poor at dealing

with large databases. The competitive advantage of jabref 3 is being able to help maintain a large, complex data base, and keep research notes for each paper. Mendalay and zotero look good and work fine for students with small databases, but impossible to maintain for large bibtex files.

  1. Having “automatic features” is a disaster for large databases - one mistake and I waste days fixing things. So today I have 5 cites to add - when I use the automatic seach I typically get the wrong file, which is put in the wrong location - wastes time. My workflow starts

with web of science -> jstor - jstor does a good job with the bibex format, which I cut and past into jabref, and then I download and rename the file, and store. Then I click add in jabref 3, and the link is there in a second.

When you do this as much as I do, time makes a different - in addition to being slow, with jabref 4 the auto link is slow, so more time is wasted.

When you guys dropped the support of parenthesis () - I had to write a python script to fix my data base - more hours wasted- anything that potentially messes up a data base has to have some clunky way to do things - automation with no control is really not a good idea…

It is worthwhile keeping in mind that heavy users need speed and reliability above all - I just do not see how you can compete with mendalay and zotero head to head given their resources. What they do not do is create a stable and efficient environment for heay uses

I see this as your competitive advantage.

As I said, ideally I would like a branch for jabref 3 that adds java 10 compatibility and keeps bugs under control.

In any case, jabref 3 is a fantastic reseearch tool - I cannot find any better tool for large databases. Unfortunately, for production use jabref 4 creates so many problems, I have to recommend my students to use jabref 3 for the moment.

For small data bases there is lots of competition - so the jabref advantage is being stable and able to handle large databases well and allow research to add notes for each paper.

Thanks again for reply and many thanks for your hard work.

best wbm

6

Hi,

thanks for your detailed feebback.

I would have preferred refinement of jabref 3 and moving it to java 9/10/

That’s technically not possible and one of the reasons why we switch to the new UI technology completely.
We are already working on java 9 support. Hopefully, version 5 will be Java 9 compatible.

when I use the automatic seach I typically get the wrong file, which is put in the wrong location - wastes time.

I don’t really understand the problem here. If you manually drag and drop the downloaded pdf on the entry in the maintable you have the option to move it to the file directory and rename it accordingly.
Otherwise you could just use “Quality-> Automatically set file links” It searches for a matching pdf in your local file folder.
And if you end up in the wrong folder, then it’s a problem of your settings. I don’t see a fault of JabRef here.

When you guys dropped the support of parenthesis ()

To what do you refer in detail? I don’t know about an issue regarding this?

Most of the devs use JabRef for their daily work, too. And we have some users with very large databases which we also internally use for testing.

Regards
Christoph