Better support for IEEEtranBSTCTL entries

[oscargus]

Added better support for the specific fields in IEEEtranBSTCTL. Especially, a new extra field "yesno" was introduced to simplify the setting of some of the fields.

[stefan-kolb]

Hm , this looks really convenient 😄
But I'm not sure if we should hard code such proprietary stuff into our application.
I was also concerned about the IEEEtranBSTCTL entry type as it really is just a hack of the style and no entry.
I think the entry type is a good compromise.
I don't know what the @JabRef/developers think about this.

[koppor]

Yes, why not 🐬? I'm not sure whether there are other bsts outside having even more different types. Think, we covered biblatex and the "ordinary" BibTeX types completely. A quick search of bst did not reveal more types. I think, even custombib does not support more types. If there is more, users can do custom entry types.

[simonharrer]

This code does not introduce complexity, but the gain is also small as this supports only a very minor edge case. I am undecided whether we should introduce this.

[koppor]

I ❤️ software which simplifies life. Therefore, this improvement should really come in 💥. A good support for the IEEE style could be advertised at the IEEEtran homepage or even at the IEEE page "Manuscript Templates for Conference Proceedings. 🐉

[lenhard]

@koppor: Your comments look as if you should be careful with your caffeine / theine intake.

[koppor]

💨 - I'm addicted to Baola and neuronade, formally known as nijoz. 🌿😇

[oscargus]

I agree that it is a minor thing. The thing is that using IEEEtranBSTCTL is actually really convenient, but non-obvious that it could/should be used. My main argument would be that the code overhead is really small and the yes/no boxes will only show up in this particular case, otherwise people will be unaware of it. (But probably quite happy when they get aware of it.)

(Originally support for this type was introduced as JabRef tended to remove/change unknown entry types, but apparently that was changed yesterday.)

I have an issue (JabRef#21) that aims at providing a special interface for this type, to simplify it even further. However, at the moment I think this is probably enough.

I'll fix the suggestion by @koppor and hope for the best.

[oscargus]

I've changed the code according to @koppor 's suggestions.

Regarding @stefan-kolb 's(?) comment that this should reside in IEEETranEntryTypes (can't find the comment now) I'm not really sure. All other field properties are defined in BibtexFields, and while it may make sense to define these things in BibtexEntryTypes, BiblatexEntryTypes, and so on, I cannot really see how it can be done in a convenient way (this could for example include field checkers, which are defined by the fields rather than the IntegrityCheck looking for specific fields). So for now, I keep this similar to the rest of the fields.

[koppor]

I also remember stefan-kolb's comment, but can't find it, too. Let's merge this and adapt it if we find the comment 😇

[oscargus]

I think I (sort of) considered what he could have meant in the final cleanup. Still, one could think about how the field properties and checkers should be defined. In the entry type definitions or in the EntryEditor/IntegrityChecker. It becomes a bit more interesting when we introduce all the new entry types.

For example, filedyear in patent: should IntegrityChecker have a list of all possible year-related fields or should IEEETranEntryTypes set some flag that filedyear is a year field?