-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Move labelpattern #1626
Move labelpattern #1626
Conversation
} | ||
|
||
public static void updateDefaultPattern() { | ||
defaultLabelPattern = AbstractLabelPattern.split(JabRefPreferences.getInstance().get(JabRefPreferences.DEFAULT_LABEL_PATTERN)); |
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.
Instead of relying on the preferences within this class, could the preference value just be passed through a parameter? Then this class would be independent of the preferences package.
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.
See #1607. :-) Not sure what is the best merging order...
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.
@simonharrer Good idea
@oscargus Oh no, now I have already rewritten GlobalLabelPattern
:-(
However, it seems you did not really touch the class in #1607? From what I have seen and tested with the GUI, you can completely drop the static part of GlobalLabelPattern
. It is just initialized in two places (the gui and the preferences) and both of these places have access to the gui, so you can provide the correct parameters right away.
Regarding merging order: I'd prefer mine to be merged first :P Anyway, let Simon decide!
No idea. Probably a bit of resolving independent of who merges first. The feeling is that it is easier to merge the PR without moving of files first, but I'm not sure if that is true or if I just want less work. ;-) |
By the way, there is a preference setting "Enforce legal characters in BibTeX keys". Is that really needed? The difference is the characters in |
@oscargus: My changes were quite small and would be relatively easy to redo, so it's ok for me if you go first. Regarding the BibTex keys: We have already upset at least one person in #1272. We talked about this issue on the devcall right now and arrived at the following decision:
|
OK! If anyone could have a look at the PR I'll merge it. So basically, the (in the PR introduced) boolean argument to |
And we considered moving the check to the integrity dialog. |
# Conflicts: # src/main/java/net/sf/jabref/gui/preftabs/LabelPatternPrefTab.java # src/main/java/net/sf/jabref/logic/labelpattern/LabelPatternUtil.java # src/main/java/net/sf/jabref/preferences/JabRefPreferences.java
Should be good to go. Just as a side note: What are the "default" buttons in Preferences-> BibTeX key generator supposed to do? For me, only the button for the default pattern works and actually resets something. The other default buttons basically just delete what I have entered into the corresponding text field. This behavior is independent of this PR. |
I think the default is that every type has the same key pattern, so it makes sense that the pattern is cleared when clicking Default. |
LGTM! 👍 |
I'm not sure whether we discussed it in this context at the last devcall, but moving those classes will lead to another node in the registry for storing those preferences - if the storing mechanism is not adjusted. |
@matthiasgeiger: Are you sure? Didn't that already happen through #1635 by introducing the new |
Just tested it: v3.5 and current master reads and writes from/to |
Caused by: https://github.com/JabRef/jabref/blob/master/src/main/java/net/sf/jabref/preferences/JabRefPreferences.java#L1151 and https://github.com/JabRef/jabref/blob/master/src/main/java/net/sf/jabref/preferences/JabRefPreferences.java#L1174 |
Migrations are overrated :-) We should at least change that to
to avoid future issues. Although not part of this PR, let us keep this open and discuss at the next devcall on how to proceed. Refs: #1257 |
Another topic for the devcall: Can we rename this "LabelPattern..." stuff to "BibtexKeyPattern..." ? - I never understood why this is called "label pattern" 😉 |
TODO in new PR after this one is merged:
|
Conflicts: src/main/java/net/sf/jabref/JabRefMain.java
Conflicts: src/main/java/net/sf/jabref/MetaData.java
* master: (22 commits) Do not cite entries without a key in OpenOffice/LibreOffice (JabRef#1682) (JabRef#1683) Got rid of unused preferences (JabRef#1672) Move labelpattern (JabRef#1626) Implementation of shared database support (full system). (JabRef#1451) Removed bst from architecture tests JabRef#1699 Update PULL_REQUEST_TEMPLATE.md French localization: Menu: Translation of an empty string French localization: Jabref_fr: empty strings translated Updated string similarity version (JabRef#1698) Minify description of release process Announce switch from GPL to MIT in CONTRIBUTING.md and README.md Some cleanups to initialize empty MetaData at fewer positions (JabRef#1696) Automatic group names are converted from LaTeX to Unicode (JabRef#1684) Update ISSUE_TEMPLATE.md (JabRef#1686) Removed (false) NPE issue reported by FindBugs More Swedish translations (JabRef#1691) Updated wiremock version (JabRef#1690) Some minor code cleanups (JabRef#1689) Removed dependencies of Globals.prefs in some tests (JabRef#1688) Lookup BibEntry from ISBN and merge information (JabRef#1621) ... # Conflicts: # src/main/java/net/sf/jabref/gui/BasePanel.java # src/main/java/net/sf/jabref/importer/ImportMenuItem.java # src/main/resources/l10n/JabRef_da.properties # src/main/resources/l10n/JabRef_de.properties # src/main/resources/l10n/JabRef_en.properties # src/main/resources/l10n/JabRef_es.properties # src/main/resources/l10n/JabRef_fa.properties # src/main/resources/l10n/JabRef_fr.properties # src/main/resources/l10n/JabRef_in.properties # src/main/resources/l10n/JabRef_it.properties # src/main/resources/l10n/JabRef_ja.properties # src/main/resources/l10n/JabRef_nl.properties # src/main/resources/l10n/JabRef_no.properties # src/main/resources/l10n/JabRef_pt_BR.properties # src/main/resources/l10n/JabRef_ru.properties # src/main/resources/l10n/JabRef_sv.properties # src/main/resources/l10n/JabRef_tr.properties # src/main/resources/l10n/JabRef_vi.properties # src/main/resources/l10n/JabRef_zh.properties
* Move classes describing the structure of label patterns into model * Remove unnecessar import * Fix checkstyle errors * Fix checkstyle errors in tests * Rewrite GlobalLabelPattern and remove static parts * Fix checkstyle error: The intellij checkstyle plugin and me will never be friends * Add getter for default label pattern * Remove unused imports
Minor refactoring and moving of classes from logic into model. The
XXXLabelPattern
classes really describe how we serialize and store label patterns (part of the structure of meta data). Hence, they belong into model and have already been almost independent of other classes. The util class with helpful functions regarding label patterns can stay in util.