Add support for book front covers

[bblhd]

Closes #10120

This pull request adds support for cover images which can display in the preview of entries. It also allows new entries to automatically download cover images from either "https://bookcover.longitood.com" or "https://covers.openlibrary.org", and preferences to control downloading behaviour. Key changes are:

• The ability for PreviewViewer to display images
• A new BookCoverFetcher class to download cover images
• Hooks in NewEntryViewModel to do cover fetching
• New options in FilePreferences and LinkedFilesTab

Steps to test

1. Add a new entry using the ISBN "978-1449310509", if you open the preview for the new entry, the cover image should be visible.
2. Under File > Preferences, in the Linked Files tab, disable the "Automatically download cover images" setting.
3. Add a new entry using the ISBN "978-1449373320", there should be no cover image if you open the preview.

Mandatory checks

• [x] I own the copyright of the code submitted and I license it under the MIT license
• [x] I manually tested my changes in running JabRef (always required)
• [x] I added JUnit tests for changes (if applicable)
• [x] I added screenshots in the PR description (if change is visible to the user)
• [x] I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
• [ ] I checked the user documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

Images

[github-actions[bot]]

Hey @bblhd!

Thank you for contributing to JabRef! Your help is truly appreciated :heart:.

We have automatic checks in place, based on which you will soon get automated feedback if any of them are failing. We also use TragBot with custom rules that scans your changes and provides some preliminary comments, before a maintainer takes a look. TragBot is still learning, and may not always be accurate. In the "Files changed" tab, you can go through its comments and just click on "Resolve conversation" if you are sure that it is incorrect, or comment on the conversation if you are doubtful.

Please re-check our contribution guide in case of any other doubts related to our contribution workflow.

[bblhd]

I have attempted to unmodify submodules without success, both in the past and currently, though I was unaware how much of a problem it was.

I've tried all suggested fixes unsuccessfully, either commit ids are not found or the commands have no effect at all. It seems to be something wrong with my version of git or my repository. For context, I'm using git version 2.51.2_1, on linux, with a basic command line and no IDE.

In theory, this could be fixed by creating a new branch and pull request, but the contributors guide specifically requests not to.

Does anyone know how to solve this?

Commit: bb58664 Diffs: csl-locales, csl-styles

[bblhd]

I have attempted to unmodify submodules without success, both in the past and currently, though I was unaware how much of a problem it was.

I've tried all suggested fixes unsuccessfully, either commit ids are not found or the commands have no effect at all. It seems to be something wrong with my version of git or my repository. For context, I'm using git version 2.51.2_1, on linux, with a basic command line and no IDE.

In theory, this could be fixed by creating a new branch and pull request, but the contributors guide specifically requests not to.

Does anyone know how to solve this?

Commit: bb58664 Diffs: csl-locales, csl-styles

Fixed this by doing submodule checkout in IntelliJ IDEA, unsure what exactly the issue was, but submodules are now unmodified from main.

[bblhd]

I apologise for force pushing, the only difference was a single incorrect author email in the previous commit I pushed.

[InAnYan]

Hi, bblhd! Thank you for looking into this feature. This is a very good issue for the first contribution!

[bblhd]

I understood:

1. The approach only supports isbn-based pictures (which is OK)

2. All files are named `isbn-xyz`

3. Covers are only downloaded for new entries

4. **Covers are attached to an entry - and thus displayed as attached file in the main table**

5. Existing covers are not re-used across different libraries (unless the configured directories match)

I think step 4 is a really big issue and hampering usability of JabRef. I cannot open an attached PDF any more with a single click.

For this PR, I propose a radical different approach:

1. Add method `getCoverDirectory` to org.jabref.logic.util.Directories

2. Store all covers there

3. Lookup covers there

No storing in BibEntry any more.

Just using ISBN and that directory for lookup

No re-download if cover already exists.

Thank you for the thorough review, it is very much appreciated.

Seperating book covers from attached files is a good idea, my current method was based off of previous attempts and what I understood of the codebase at the time, but its flaws became more obvious as I worked on it and understood more of the way that JabRef is actually used. I was considering this type of approach, so confirmation and details is helpful, I will be implementing seperate covers going forward.

[koppor]

Seperating book covers from attached files is a good idea, my current method was based off of previous attempts and what I understood of the codebase at the time, but its flaws became more obvious as I worked on it and understood more of the way that JabRef is actually used. I was considering this type of approach, so confirmation and details is helpful, I will be implementing seperate covers going forward.

Nice! - Yeah, we are hitting the trade-off between 100% crisp requirements (causing much time) and implementing a solution and needed to change based on feedback. -- Its always easier to see something when it is "tangible" than when it is written somehow vaguely.

Thank you for the endurance!

---

If you want, you can write down an ADR (docs/decisions), because you know have material for both options.

[jabref-machine]

JUnit tests of jabkit are failing. You can see which checks are failing by locating the box "Some checks were not successful" on the pull request page. To see the test output, locate "Source Code Tests / Unit tests (pull_request)" and click on it.

You can then run these tests in IntelliJ to reproduce the failing tests locally. We offer a quick test running howto in the section Final build system checks in our setup guide.