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. |
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 ^^. |
calixtus
left a comment
There was a problem hiding this comment.
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.
Could be done in directly in FXML. (disabled=${grobidEnabled.selected}) or similar. Lot's of examples elsewhere...
There was a problem hiding this comment.
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.
|
|
||
| @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.
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.
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.
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.mddescribed in a way that is understandable for the average user (if applicable)