Grobid config panel with check box

[hanachaari]

This fixes koppor#566, which is related to Grobid preferences.

I have changed Grobid preferences from a checkbox to a Radio-Button-Group (disable, enable, always ask).

This is the new configuration panel

The dialog below appears as long as the user does not check "do not ask again" or change preferences .

Despite the decision as mentioned here koppor#566 (comment) was to remove the "do not ask checkbox", I think it is not recommended from a UX perspective. So, I provided two versions: the branch: "gorbidConfigPanel" without a checkbox and the branch"gorbidConfigPanelWithCheckBox" with a checkbox.
The checkbox in the later branch is synchronized so when it is checked Grobid preferences will be "disabled" or "enabled" according to the user's answer(yes/no).

Compulsory checks

Beta Give feedback

1. Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
2. Tests created for changes (if applicable)
3. Manually tested changed features in running JabRef (always required)
4. Screenshots added in PR description (for UI changes)
5. Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
6. Checked 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 to the documentation repository.

[Siedlerchr]

No need to close/open the PR everytime. Just push the new code, the PR will be updated automatically and the CI will run on every push

[Siedlerchr]

And for checkstyle https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace.html#using-jabrefs-code-style

[hanachaari]

I am facing a failure with the fetcher test.

The error message suggests the optional link to the PDF file is empty so not found. I checked the source website and I found it, so It may be a problem with the implementation of the retrieval code

[ThiloteE]

To ease organizational workflows I have linked the pull-request to the issue with syntax as described in https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

Linking a pull request to an issue using a keyword

You can link a pull request to an issue by using a supported keyword in the pull request's description or in a commit message. The pull request must be on the default branch.

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

If you use a keyword to reference a pull request comment in another pull request, the pull requests will be linked. Merging the referencing pull request also closes the referenced pull request.

The syntax for closing keywords depends on whether the issue is in the same repository as the pull request.

[Siedlerchr]

I am facing a failure with the fetcher test. The error message suggests the optional link to the PDF file is empty so not found. I checked the source website and I found it, so It may be a problem with the implementation of the retrieval code

If you did not touch the fetcher, you can ignore the failing tests. Sometimes they will fail on the CI but work locally

[koppor]

Dear @hanachaari,

Thank you for working on JabRef.

Despite the decision as mentioned here koppor#566 (comment) was to remove the "do not ask checkbox", I think it is not recommended from a UX perspective.

Maybe you overlooked following text in the isse:

A huge discussion was going on at #9291.

Link: koppor#566 (comment). We even specified the behavior with that box: #9291 (comment). It was "smashe away": #9291 (comment)

Main reason:

That wouldn't be possible of course. But as I said above, I don't see the real use case for this. Why would a user want to be asked every time?

So, please: No checkbox.

Please do Enable GROBID, Disable GROBID in the preferences.

I follow the argument of Tobias at #9291 (comment):

Upon the first use of the feature (if grobid is not explicitly enabled already), ask the user. Depending on the answer, set the preference to "enable" or "disabled".

That means, the preference should have a setting if the user has already been asked. That can be done by an enum: FIRST_START, ENABLED, DISABLED. Preference storing/retrieval might be difficult. @calixtus WDYT?

[koppor]

See above.

[calixtus]

I'm somewhat impressed you implemented this checkbox as a commonfxcontrol, which was probably no easy. But... Parsing fxml needs a lot of time. If this prefs option is not used anywhere again, I would ask you to integrate it directly in the prefs tab.

About the enum, yes, sounds like a good idea. But please don't change the implementation in JabRefPreferences using the BackingStore or we'll have multiple users annoyed being asked again on start if they want or don't want to use grobid.

[hanachaari]

Updates on #9802

[calixtus]

Thanks for your ongoing interest in jabref.
Again, implementing this as a FX control is impressive and shows good understanding of javafx, but it does cost unnecessary computing time and resource to parse the fxml. Please integrate it directly in the tab. Also a radio switch is from the UX perrspective way too much for such a simple preference option. Please use just a checkbox titled "enable grobid" and ask for the grobid orl in the next line.

[calixtus]

.

[koppor]

Superseeded by #9802.