Based on some earlier discussions, e.g., JabRef#59 #967 JabRef#32 , it seems to make sense to redefine and restructure the properties of each field. At the moment it is handled by https://github.com/JabRef/jabref/blob/master/src/main/java/net/sf/jabref/gui/InternalBibtexFields.java and especially the class BibtexSingleField in that file.

Currently the following properties are defined:

• final String name; - the name of the field
• int flag - a combination of

        private static final int STANDARD = 0x01; // it is a standard bibtex-field
        private static final int PRIVATE = 0x02; // internal use, e.g. owner, timestamp
        private static final int DISPLAYABLE = 0x04; // These fields cannot be shown inside the source editor panel
        private static final int WRITEABLE = 0x08; // These fields will not be saved to the .bib file.

• int length - field length in characters(?)
• double weight - weight factor used for relative row size in the entry editor columns(?)
• int editorType - may be one of

    // constants for editor types:
    public static final int STANDARD_EDITOR = 1;
    public static final int FILE_LIST_EDITOR = 2;

• String extras; - Determines any extra component in the entry editor, currently one of:

    public static final String EXTRA_YES_NO = "yesNo"; // Blank/Yes/No Combo-box
    public static final String EXTRA_URL = "url"; // Drop target for URL
    public static final String EXTRA_DATEPICKER = "datepicker"; // Calendar button and double-click in field to set current date
    public static final String EXTRA_JOURNAL_NAMES = "journalNames"; // Journal abbreviation button
    public static final String EXTRA_EXTERNAL = "external"; // Open external viewer on double-click
    public static final String EXTRA_BROWSE = "browse"; // Browse button, file dialog
    public static final String EXTRA_SET_OWNER = "setOwner"; // Button to set owner to current used
    public static final String EXTRA_MONTH = "month"; // Button to show the months and set abbreviation

• boolean numeric; - true if the field is expected to be numeric and in that way one can sort based on that

My idea is to extend this. Currently, there are quite a lot of different fields, especially in Biblatex that has the "same" properties. For example, there are about ten or so different fields with names defined and it would be much better if one could check field.isNameField() instead of comparing against all the possible field names (now, mainly author and editor is checked). This would be useful for e.g. the integrity checks. Similarly, it would make sense if the field knew how it should be sorted (e.g. the date field in biblatex could use a dedicated comparator). Also, some fields can only take on specific values, either from a list (like month or languague) or being a number, like year. From a layout perspective, it is discussed in #967 that different fields should have minimum/maximum sizes and that some benefit from resizing, some not. Add to that alignment and the size required in the entry editor.

The purpose of this issue is to try to come up with a good redesign of BibtexSingleField. It appears to me as there are a few larger problems here:

1. Which properties should be included?
2. How is this mapped in practice from fieldname to property? Probably one should refactor and move this to logic as some methods in logic right now tests for fieldname.
3. How should they be set (and saved) in practice? Like today, but extended? Would somehow be nicer if each type (or class of types) has the default knowledge.
4. What about defining custom fields?
5. Is this saved per database or in the preferences?

To this end, I'd suggest the following fields:

• String name
• int flag - as before
• int type - Combination of the following constants (numerical value tbd, probably more are needed, the Biblatex manual decribes this pretty well)
  • namelist - for author names - gives the field editor button and triggers "correct" integrity checkers
  • keyword - field editor, can be set for other fields as well (which some people appears to be using)
  • journal - journal list/abbreviation
  • title - integrity check
  • date - date picker, special sorter, integrity check
  • month - month list, integrity check (number in Biblatex)
  • integer - numerical sorting, only numerical value(?) (used for e.g. year, maybe number and volume, some IEEE fields)
  • pagerange - integrity checker
  • file - file-field parsing
  • yesno - IEEE yes/no
  • language - select among languages (is a list)
  • pagination - list of pagination alternatives
  • editortype - list of editor type alternatives
  • texcode - probably warn if one runs latex to unicode conversion on this field...
  • uri - droptarget for URL, possibility to open URL
  • doi - special handling and checking
  • owner - set owner on double-click
  • crossref - must be a bibtexkey
  • gender - list of alternatives
  • options - key=value pairs
  • related - bibtexkeys (not what is sometimes discussed as "referenced by" etc)
  • relatedtype - list of options (see Biblatex documentation)

Entry editor related

• double weight - as before

Main table related

• boolean resizable
• int minimalSize
• int maximalSize
• LayoutFormatter layoutFormatter - should a layoutformatter be used for the field and in that case which(?)
• boolean resolve - should the field be resolved for strings(?)
• Comparator comparator ? or handle by type?
• int alignment - one of left, right, center (are there use cases for center? Numbers should probably be right-aligned anyway)