-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preferences for Grobid #8002
Preferences for Grobid #8002
Conversation
There are two things left to do:
|
You can use Example:
|
Looks promising, but I am having trouble deciding when to show the dialogue. We can show it either when JabRef opens. This is the easiest option to implement but a little intrusive. The second option is to show it when a user triggers an action that requires Grobid. There are multiple actions that trigger Grobid:
I started implementing the second option, but there is a lot of code to change and it is not pretty IMHO. What do you think? Shall I continue implementing it that way or do we want to go the first route, asking the users when JabRef launches? They can immediately opt out and never see the dialogue again. |
src/main/java/org/jabref/gui/bibtexextractor/ExtractBibtexDialog.java
Outdated
Show resolved
Hide resolved
This is the behavior, I would expect. Later, we can add some welcome screen enabling well-used default preferences (enable all online services, ...). Refs https://github.com/koppor/jabref/issues/96.
Yeah. I would still keep the number of questions at the start low.
OMG - nested dialogues. A work around could be to "cheat" and show the confirmation before the other. However, this is not a very good approach ^^. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nitpicks for codestyle and readability.
Did not expect to grow introduction of prefs for grobid so large, but seems reasonable.
Use of Globals is not nice, but in the current state of JabRefPreferences necessary, @DominikVoigt and me are diving into this issue these days.
|
||
grobidEnabled.selectedProperty().bindBidirectional(viewModel.grobidEnabledProperty()); | ||
grobidURL.textProperty().bindBidirectional(viewModel.grobidURLProperty()); | ||
grobidURL.disableProperty().bind(grobidEnabled.selectedProperty().not()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be done in directly in FXML. (disabled=${grobidEnabled.selected}
) or similar. Lot's of examples elsewhere...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's possible here because you can't do the negation in fxml. It needs to be disabled if grobidEnabled is NOT selected.
@@ -72,6 +73,11 @@ public void processInvalidCitationTest() { | |||
assertThrows(IOException.class, () -> grobidService.processCitation("iiiiiiiiiiiiiiiiiiiiiiii", importFormatPreferences, GrobidService.ConsolidateCitations.WITH_METADATA)); | |||
} | |||
|
|||
@Test | |||
public void failsWhenGrobidDisabled() { | |||
assertThrows(UnsupportedOperationException.class, () -> new GrobidService(new ImportSettingsPreferences(false, false, false, "http://grobid.jabref.org:8070"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe extract the ImportSettingsPreferences (I hate that name) to a separate variable, following the typical test scheme:
// given
...
// when
...
// then
...
See https://blog.codecentric.de/en/2017/09/given-when-then-in-junit-tests/ for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracting is easy and I agree it is more readable. For the 'when' clause, since I expect an exception, something like this would be necessary. In my opition expectThrows is easier to read though. Is it ok to violate given-when-then in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a hard law, but a suggestion. Should make reading and understanding tests easier. If in this case it's not, then ok.
Changelog necessary? |
You are right, since this also affects the plaintext-import that was already released, a Changelog entry is necessary. |
Implements two new preferences in ImportSettingsPreferences:
The preferences are used in the Fetchers and Importers that use Grobid. Creating a GrobidService while grobidEnabled is false will result in an UnsupportedOperationException.
Fixes #8000
CHANGELOG.md
described in a way that is understandable for the average user (if applicable)