-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Enhance customization of entry types #9840
Comments
Hey team, can i work on this issue? |
As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at. Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback. |
Hi, can you please explain more about the first todo? Not sure about what setting zero or more FieldProperty means. |
@eric052199 For me, it is not clear, what is unclear to you ^^. I try to write a few text on "Enable setting zero ore more org.jabref.model.entry.field.FieldPropertys." Please ask which item should I refine or if you need additional information.
.orElse(new UnknownField(fieldName));
Hints:
|
"BibTEX does not distinguish between normal and capital letters in entry and field names" |
The entry field casing is the least important wish of the issue. I have removed the requirement to put the focus on the important code changes. Background information: The field capitalization refs JabRef/blog.jabref.org#47 and #8676 |
After this is fixed, please check if #5857 is also fixed. |
@eric052199 I saw activity on the minor TODOs of this PR. May I ask if you work on the big TODO, too? |
@DinjerChang @eric052199 #9993 is now merged. Now, it should be even more easy to work to fix this issue. Please remind my hints at #9840 (comment). Please reach out if something is unclear. |
@koppor Thank you very much! I'll hop on to it after finals. |
@koppor I currently used a checkComboBox from
Not sure if I'm on the right track and would love to discuss more |
Thank you for continuing working on this. The dropdown with the selection allements is good. I would suggest to modify the field labels of the add buttons to really show the action taken " The property can be empty, then you can show ("default") in gray (if that is possible in JavaFX). Otherwise, leave the box empty. In case the user modifies the field name on the left and the field does not exist, the button label " You can also add a button with the small circle" next to the " |
@shihar94 are you also a member of @DinjerChang and @eric052199's team? I appreciate your effort, but have you seen they are already working on it? |
@ThiloteE |
Thank you very much. In most cases, we try to keep issues and projects for students separate, so as to not interfere with any grading method that is not compatible with outside interference. |
Correct me if I'm wrong :) |
I don't understand "could have access". - These properties should be rendered in the UI but not modifiable for standard fields. For Unknown fields, they should both be rendered and modifable.
Reads good.
Need to think longer. Can only write the rough idea: The FieldViewModel is a "factory" for the final model. The idea is that an object goes into the ViewModel, which extracts data from that. Then it is modified. Then, a new object is created from that data. Reason: the incoming object might be a "constant" object. All ViewModels should be implemented the same way. @calixtus Maybe you have something to add? |
@koppor Sorry for the unclear explanation of Section 1. What I've done right now,
|
Please leave the good first issues label on. |
Thanks. I'm not very experienced with javaFX, I have experience with java spring for backend, but I will dedicate myself to solving this problem. |
Hey guys, I'm having a lot of difficulty completing this task, I'm going to unassign me here and try to find another task. Sorry |
@IsaacDMz Okay, if you need some inspiration: You can browse through our project lists: |
Can i work on the first todo of this issue? |
@nio2004 sure. I will assign you. |
Hi. Can I continue working on this issue? |
Apparently, yes. Nice catch for noticing nobody was assigned ;-) |
This issue is free to take again! There is still only one thing missing |
Hey. I'd like to work on this issue, can you assign me to it? Thanks :) |
@enesbkoca Nice! Looking forward! |
Hi, I've looked into this issue, and it seems to be more complicated than I initially thought and due to time constraints I'm afraid I will not be able to implement this issue. For this reason I'd like to be unassigned, my apologies. |
Hi! I’d like to take up this issue |
Hi @aqurilla, nice to see you again :-) |
@ThiloteE thankyou, happy to be back! :D |
This change will add to the proliferation of undocumented entry types that will probably be shared with colleagues and in the wild. Maybe there should be some kind of documentation or "info" that points to the biblatex issue tracker for people that want to make their entry type "official". |
As user, I want to create a new entry type. For example, a new entry type "Person" with "name" and "googlescholar" as fields. JabRef offers advanced field handling for names, URLs, and more. This is implemented using
org.jabref.model.entry.field.FieldProperty
. The current dialog enables only the addition and deletion of fields. Not assigning field properties or changing the name.Thus, TODOs:
org.jabref.model.entry.field.FieldProperty
s. Should be done in a combo-box allowing multiple selections.Enable update of name: I cannot fix typos in the name -- it should be possible to double click the name and then change the value:Optional: Enable casing: I tried to add "GoogleScholar", but I could not type the capital "s". I think, users should be allowed to use arbitrary casing?More information
jabref/src/main/java/org/jabref/model/entry/field/InternalField.java
Line 57 in 6269698
The text was updated successfully, but these errors were encountered: