-
-
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
Enable editing typo with double clicking on field name in custom entry type #9977
Conversation
mrege jabref main to dinjer jabref main
…he fieldname to backend
} else { | ||
dialogService.showWarningDialogAndWait( | ||
Localization.lang("Duplicate fields"), | ||
Localization.lang("Warning: You added field \"%0\" twice. Only one will be kept.", newFieldValue)); | ||
event.getTableView().edit(-1, null); | ||
event.getTableView().refresh(); | ||
} |
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.
Modern software seldom makes use of popups. I would use the notifiy
functionality. The user has no choice. Moreover, the current code keeps the old casing. Thus, instead of newFieldValue
, the existing one should be output. As a consequence, the code of fieldExists
needs to be modified accordingly.
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.
The reason I use newFieldValue
instead of the existing one is to see if the user input value (newFieldValue
) exist in the current fields. Let's say we already have two new Field, Name and Test. When a user try to edit Name to Test, he would double click the Name Field and type "Test", so "Test" is the newFieldValue. So I think we have to see what user input is and compare it with the existing Field. In this case, Test already exist, so we will notify the user.
If we choose the existing one by using the method field.getDisplayName()
, the value would be Name since we haven't modify the field yet. In this case, we always get the fieldExists
value to be True
Also, I'm replacing equals
with equlsIgnoreCase
to handle the casing comparison problem.
Let's say a user edit Name to name, it should be and will be seen as duplicate field.
Let me know if I understand statement correctly and if I'm on the right track :)
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.
Sorry that I was not clear in my terms. Thank you for explaining a scenario. I hope, this short explanation based on your scenario helps:
I was trying to say: User renames to TEST, but Test exists. I assume the user knows, he input TEST, but forgot about the existing field Test. Therefore, Test should be displayed and not TEST.
…ing user input value with existing value of field
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.
One more thing:
- Double click on a field
- Press enter
Expected behavior: Field is as kept as is - and no notificaiton is output
Actual behavior: Field is kapt AND an notification is output:
I think, in if (fieldExists)
inside an additional check needs to be made. Maybe also before - if the old name is the new name
src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java
Show resolved
Hide resolved
src/main/java/org/jabref/gui/preferences/customentrytypes/CustomEntryTypesTab.java
Outdated
Show resolved
Hide resolved
…fter double click then click enter, change negataion to positvie of fieldExists
boolean fieldExists = entryFields.stream().anyMatch(fieldViewModel -> | ||
fieldViewModel.nameProperty().getValue().equalsIgnoreCase(newFieldValue)); | ||
fieldViewModel.nameProperty().getValue().equalsIgnoreCase(newFieldValue) && !newFieldValue.equals(field.getDisplayName())); |
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.
The new condition does not make use of ´fieldViewModel `
I think, following code matches your intention:
boolean fieldExists = !newFieldValue.equals(field.getDisplayName()) && entryFields.stream().anyMatch(fieldViewModel ->
fieldViewModel.nameProperty().getValue().equalsIgnoreCase(newFieldValue));
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.
You're right. I shouldn't put it in the anyMatch()
method when streaming
…abref into fix-for-issue-9840
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.
Thank you for keeping working on this!
I think, UI tests for this are hard. Thus, this PR is OK from my side!
@DinjerChang In future, please chechk if an issue is assigned to a person and if the person is on your team. It seams that the issue was assigned to @eric052199, which probably is not on your team? -- Do you intend to work on the first item of the TODO, too? |
Modified changelog, since this was not a fix for a bug, but a small and most welcome enhancement. Thanks! |
@koppor @calixtus Sorry I forgot to mention that Eric and I are on the same team. |
@DinjerChang That sounds good. I would suggest you create a new PR then and we merge this one |
While discussing it with a group of maintainers of JabRef, we worked on the code again: PR is #9993. We hope to get this merged the next days, so that you have a good foundation to work on the core issue. For the different field properties, a good start are tests. A skeletton is provided at https://github.com/JabRef/jabref/pull/9993/files#diff-420e1dfef38c9004e74cc9b2074499e837558303f00e177c9312ccd38def62e1. It could be used to work on the serialization format proposed at step 10 at #9840 (comment). |
* upstream/main: (68 commits) Fix issue 9863 - Change Tab selection order (#9907) New Crowdin updates (#9994) Enable editing typo with double clicking on field name in custom entry type (#9977) Remove "Field name:" from localization - we already have "Field name" (#9991) Changed database to catalog in org.jabref.gui.slr and org.jabref.logic.crawler (#9989) Use environment variables for hostname detection (#9910) Add cleanup activity for URL field (#9970) Fix freezing when fetching IBSN and no results are found (#9987) Make Group(Node)TreeViewModel more OO (#9978) Fix container for group item count still visible if display count is off (#9980) Fix paste of BibTeX data (#9985) Bring back SimplifyBoolean* and UnnecessaryParantheses (and refine guide) (#9981) Add new menu entry to remove braces from selection, aka unprotect it. (#9968) User specific comment (#9727) Bump org.openrewrite.recipe:rewrite-recipe-bom from 1.19.3 to 2.0.0 (#9975) Fix typos Remove non-needed link Fix typos Enable RemoveJavaDocAuthorTag (#9973) Bump com.fasterxml.jackson.datatype:jackson-datatype-jsr310 (#9974) ...
References #9840
This PR is related to the second todo in #9840
We enable the editing feature for user when they have typo when customizing the new field.
Mandatory checks
CHANGELOG.md
described in a way that is understandable for the average user (if applicable)