Change optional fields tabs

[a1819644]

Fixes #4688

The changes we have made are the followings :

• delete OtherFieldsTab.java class, OptionalFields2Tab.java files from the jabref
  why-> as we were merging the optionalfields tab and otherFieldsTab, these both java class files existence were not required anymore. Hence got deleted.

• Deleted +136 to +151 lines of code from FieldEditorTab.java
  why->these lines of the codes were responsible the column division. As a result of this merged text field were looking ugly(see the fig-1.1 and fig-1.2)
  
  

• updated the code of the OptionalsTabBase.java
  why-> we wrote the codes for merging the field of the requested tab.

---> Tittle pr : Fix issue #4688 by UofA

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

How to see the fix:

1. Create a new lib
   

2. Click on the "new Entry" as marked on the snapshot and then add the doi of any article or your preferred the document type.
   

3. Last thing is just double click on the entry to see the changes.
   

[ThiloteE]

Thank you for the PR :-) This still needs a few changes though. I tried the pr and for the following entry no optional fields are showing in the optional fields tab apart from the files, the publisher and citationkey fields (which is bad):

@Article{LuoEtAl20200523cpa,
  author       = {Mufan Luo and Jeffrey T. Hancock and David M. Markowitz},
  date         = {2020-05-23},
  journaltitle = {Communication Research},
  title        = {Credibility Perceptions and Detection Accuracy of Fake News Headlines on Social Media: Effects of Truth-Bias and Endorsement Cues},
  doi          = {10.1177/0093650220921321},
  eid          = {009365022092132},
  number       = {2},
  pages        = {171--195},
  volume       = {49},
  file         = {:Luo et al. (2020-05-23) Fake news. Effects of Truth-Bias and Endorsement Cues.pdf:PDF},
  publisher    = {{SAGE} Publications},
}

See here:

On the plus side: the other fields tab is gone :)

In comparison the same entry with original JabRef:

I guess you deleted a little bit too much code xD

[a1819644]

Ohh, sure I will have a look as soon as possible.

[calixtus]

Thanks for your interest in JabRef development.

As your changes are affecting several fundamental concepts of the JabRef entry editor UI please provide some rationale for your changes, preferably in an ADR (https://devdocs.jabref.org/adr.html) discussing the pros and cons with proper constraints (can be kept short), so we could make a decision about the further ui development in the next devcall.

Please mind that biblatex itself is distinguishing between required entry fields and optional entry fields. Yet there are still fields left, that are not used by the entry field description for an entry type (the formerly called 'other fields') and the deprecated fields, that biblatex is not using anymore. I totally agree that using multiple tabs to provide access to the optional fields, the other fields and deprecated fields is not the most intuitive and understandable way. If you decide to merge the tabs for different kinds of fields - what you can do - you still need to somehow distinguish between the different kind of fields for an entry type, so it is clear for the user, which fields are part of the biblatex standard for that field in specific (https://ctan.ebinger.cc/tex-archive/macros/latex/contrib/biblatex/doc/biblatex.pdf) and which are not. Maybe a small heading between the fields is possible or to display them in a slightly different color...

Also mind that the compressed version of the entry editor is especially provided in case someone wants to put the entry preview in a seperate tab. In that case the fields would take the whole width of the entry editor. This is in my eyes a total waste of screen space as well as needless scrolling around in the entry editor to find the right field. Just because 'it's ugly' is imho no argument at all. Maybe a better approach would be to make the compressed view of the empty editor dependend on if the preview tab is shown seperately?

Also you should create only one pull request per feature change. In this PR we need to handle now two completly different issues (abandon the compressed view AND merge the different tabs for fields) in one. What if we agree to merge one, but not the other?

Thanks!

[calixtus]

Any update here?

[ThiloteE]

Closing this pr to reduce the number of open pull-requests. (This pr definitely cannot be merged in this stage and the pr looks kinda stale).

Feel free to reopen, once/if you decide to continue working on this.