Rethink implementation of special fields

[koppor]

Should special fields be implemented as a special kind of groups? See JabRef#363 (comment)

Pro:

• Might offer to configure arbitrary special fields instead the hard-coded ones (ranking, priority, quality, ...)

Con:

• Possibly, this causes too much effort in the UI (especially: table columns)

[tobiasdiez]

I understand special fields as fields for which JabRef has some special handling. For example, support drop-down boxes with pre-defined values (e.g. reading status) or show nice icons (e.g. quality assured).
However, such actions can't be described by the user in a convenient way. Thus I would keep the current implementation.

[koppor]

Add a new kind of group - the special group. 😇 - It defines a list of possible values and icons for each value. If the group has one member only, it is a toggle thing (Printed). If it has more members, the other behavior (Prio) is done.

[oscargus]

While not so hard to add new fields, I do not really find it realistic to add user configurability. This is primarily said considering the UI. From some perspective one can already do something similar with custom fields and/or keywords, it is just the UI and the possibility to store the field automatically as a keyword that differs.

Not sure how things work right now, but one might think of adding some easy filtering/groups for the special fields, so a dynamic group with the field icons etc.

Finally, I haven't really looked at the code more than from the perspective of separating things. Turned out it wasn't so easy because of SpecialFieldValue (or rather, the current implementation is actually quite nice, except for the separation issue).

[koppor]

devcall decision: leave as is