You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Private fields (fields marked with net.sf.jabref.gui.InternalBibtexFields.BibtexSingleField.PRIVATE), seem to be fields introduced by JabRef itself. For instance, owner and timestamp. There are also fields such as entrytype, which seem to be deprecated or can be removed.
Proposal: Introduce "JabRef fields" (owner, timestamp, maybe special fields (refs JabRef#84), ...) and move the other fields (type, bibtexkey, ...) as properties of BibEntry
We have to get rid of the private flag and make use of the displayable and writable flag only. These flags are required for the current implementation of special fields.
Alternatively, we can get rid of displayable and writable and use private for fields neither displayable nor writable (only required for special fields when stored in keywords; when written as separate fields, they are non-private and handled normally).
Even better, not misusing bibtex fields at all. Regarding the current implementation of special fields, it might be impossible to do so without changing the special fields implementation. See JabRef#84.
Private fields (fields marked with
net.sf.jabref.gui.InternalBibtexFields.BibtexSingleField.PRIVATE
), seem to be fields introduced by JabRef itself. For instance,owner
andtimestamp
. There are also fields such asentrytype
, which seem to be deprecated or can be removed.Proposal: Introduce "JabRef fields" (owner, timestamp, maybe special fields (refs JabRef#84), ...) and move the other fields (type, bibtexkey, ...) as properties of
BibEntry
We have to get rid of the private flag and make use of the displayable and writable flag only. These flags are required for the current implementation of special fields.
Alternatively, we can get rid of displayable and writable and use private for fields neither displayable nor writable (only required for special fields when stored in keywords; when written as separate fields, they are non-private and handled normally).
Even better, not misusing bibtex fields at all. Regarding the current implementation of special fields, it might be impossible to do so without changing the special fields implementation. See JabRef#84.
Refs #574
The text was updated successfully, but these errors were encountered: