[WIP] UI consistency polish

[calixtus]

Some looks and some behaviour of JabRef are not consistent or not intuitive.
This PR should equalize some of it.

As standard behaviour and look, I'm using the protected terms dialog (it already was like this before I came to JabRef) [on the left] and the special name formatters tab in the preferences [on the right].

---

I started by fixing some malfunctioning keyEvents in the preferences and the view of the StringEditorDialog.

(left old - right new)

More to come. Suggestions? Critics?

Hopefully after this PR is done, some Screenshots can be taken for the documentation.

• Change in CHANGELOG.md described (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for bigger UI changes)
• Checked documentation: Is the information available and up to date? If not: Issue created at https://github.com/JabRef/user-documentation/issues.

[tobiasdiez]

It's definitely a good idea to make the UI more uniform. Your changes also look good to me.

The only thing where I'm unsure is about the best way to add new rows. The two options are:

1. Button below the table that inserts a new empty row, which then can be changed by the user (old behavior of StringEditorDialog)
2. Text fields below the table with a button that adds the input as a new row (current behavior of special name formatters tab)

I find option 1 a bit more intuitive if the data does not require complex validation, there are only a few columns and the input is really a 1:1 version of the table data.

What's the recommendation of our UI expert @MartinKarim?

[calixtus]

I agree that adding a new line by option 1 is somehow more intuitive. However, I decided to go for the second option, because I had problems to distinguish between a new cell and the empty space below. This is probably an issue about the cellfactory or the theme.
I will try to refine a prototype to compare.

[tobiasdiez]

In the ideal case, the newly created row is selected and put in edit mode automatically, so that the user can start typing immediately.

[calixtus]

I looked into this a bit. The obstacle is, that the textfield in the edit cell is not accessible, so it can request the focus. This means that I have to create a custom implementation of the edit cell. I think I've seen this already somewhere else in the codebase, so it's not infernal stuff.
Maybe I'll find some time for that at Christmas.

[tobiasdiez]

You might be able to get the text field using Node.lookup(...).

[calixtus]

Happy new year. I've cherrypicked the important commits into another branch, but was unfortunately not able to merge the latest master into the branch, which is the basis for this PR. So i'm going to close this PR, work on the other branch and create another PR after my oral exams in the end of january.