Other fields fix and changes

[grimes2]

These are the claimed improvements:

• Removed optional fields from other fields (BibTeX)
• Removed deprecated fields from other fields (BibLaTeX)

See: #2064

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)

[Siedlerchr]

I'm sorry, but I am not sure if I get/understand your changes, because what does "OtherFields" refer to?

I have the following tabs. in BibTex:
Required, Optional, General, Abstract, Review, Source
and in Biblatex:
Required, Optional1, Optional2, Deprecated, General, Abstract, Review, Source

Deprecated fields exist for bibtex compatibility, when you import an entry you often get in bibtex.
So these fields are somehow still required.

[grimes2]

Tab Other fields shows the remaining fields:

[grimes2]

I think I found the bug in #2064. It was not a regression. A new entry editor was not instantiated on changing an entry of the same type. So some "other fields" were not displayed.

[grimes2]

Please set label "ready-for-review". Thanks.

[Siedlerchr]

In general the code looks good. I have only no clue for which reason the entry editor originally was cached and if the removal has any performance aspects.

[grimes2]

The idea was originally to have a better performance. So the entry editor is retained for the same type. This is not a good idea. The entry editor needs to be build completetely new in all cases, because the new entry can have some additional (layout changing) other fields.

[tobiasdiez]

So the whole entryEditors list can be deleted, right? (because its sole purpose was to cache the entry editor for each type). Moreover, there is a similar code in the showEntry method which differentiates between cached vs not-yet-cached.

[grimes2]

//To indicate which entry is currently shown.
private final Map<String, EntryEditor> entryEditors = new HashMap<>();

I think, entryEditors stores all the old entry editors and the new entry editor. So I'm not sure, that the sole purpose is to store an entry editor of each type. The similar code in showEntry should also be adjusted, but there is currently no bug report for it.

[grimes2]

I've checked the code. @tobiasdiez you are right. The whole entry editor caching (for each type) can be removed. I have no performance issues with my databases.

[tobiasdiez]

I noticed a very small latency if you quickly switch from editing one entry to another (for example with the arrow keys). But as I don't think this is a big deal, I'll merge this PR now.

[grimes2]

Yes, fast scrolling of the entries causes a small latency and moderate CPU usage. But I think, this is no problem. I have an idea for caching the entry editor: entry editor A -> B -> A. A can be cached. But this takes real effect only on heavy usage of the database.

[koppor]

Or cache based on the "properties" of the entry. One could generate a unique ID for each entry property. -- Property: entry type, other fields. (future: hadPDFAttached) @Braunch

[tobiasdiez]

The problem is generating the textfields. So especially in biblatex mode there are around 80 fields which are generated every time. I would not cache the whole editor but just generate the textboxes when the tab is focused.

[grimes2]

The other field tab is optional (No field -> No tab). I would prefer to create the other fields tab always (No field -> Empty tab). The advantage is, that every entry editor has always the same layout of the tabs. This preserves the active (other fields) tab on changing the entry.