Customizable drop down menus for general fields are gone

[wilthan]

Until 3.6 I had a drop down menu set up in a custom general field.
The code in the bib file was:

"@Comment{jabref-meta: selector_status:approved;captured;captured, references   only;marked;needGDCmod;not to capture;order;ordered;cancelled by library;out of    scope;printed;processing;recieved;status;}"

This option is now gone and the line is deleted when I save the file with:
JabRef 3.7dev--snapshot--2016-10-18--master--8f7ae51
windows 7 6.1 amd64
Java 1.8.0_66

It's a bug for me but I'm not sure if it was decided to remove this feature.

Put the excerpt of the log file here

[koppor]

They have been removed in #2068.

I personally never used them. I guess, your use case is to quickly change the content of a field with pre-defined words?

Could you provide a screenshot of the selectors in action? Could you elaborate a bit more why this was a useful feature and why the auto completion does not help?

An alternative could be the special fields, but they are hard-coded, whereas you seem to search for arbitrary flags.

@lenhard @tobiasdiez

[lenhard]

Wow, so there are indeed people who seemed to have used that feature. It should not be too hard to revert the PR, I guess, but the question is if we really want to. As far as I see it, adding a special term to some field (keywords, other, etc.) would achieve the same and we would not have to maintain and drag along the UI parts. @wilthan Some motivation on why this feature is important, should be re-added and cannot simply be replaced by some other existing mechanism would be nice! Then we could discuss what we do at the next devcall.

[koppor]

There was also the feature request 669 on sourceforge, which required the feature for "the systematic review of medical outcome literature, an important process in the practice of evidence based medicine (EBM)". If I understood that correctly, with customizable combo boxes, JabRef could possible ease the review process of researchers.

[lenhard]

@koppor: So did they ever develop the plugin they promised in that feature request? I am unable to find it.

[wilthan]

The difference to auto complete for me is that you get a list of options presented. If you don't know the available options you can't use autocomplete.
I implemented a custom field labeled: status
The options there were:

• approved
• captured
• references only
• marked
• order (from library)
• ordered
• out of scope

With the drop down my students were able to just pick from the list to update the status of a specific reference.

[lenhard]

@wilthan So we talked about this during the devcall and can see the point in the feature. We will re-introduce it, but the schedule is currently too tight for the release of JabRef 3.7 (which is imminent).

We will try to get the feature back into the 3.8 release, however. If the feature is absolutely crucial to you, we would ask you to stay with the older version you are currently using.

[wilthan]

@lenhard Thank you for being so responsive and accommodating to user questions and requests. We'll manage until the feature shows up again in the dev. version of 3.8.

[olivierfruchart]

I fully support the reintroduction of this feature, which is handy to check a list and avoid introducing duplicate keywords. By the way, in version 3.6 the alphabetical order of a list was shuffled upon introducing a keyword through the 'manage' action, upon adding a keyword and validating. Would be nice to keep alphabetical order.

[koppor]

Please file a separate issue. The two seem to be unrelated and it is likely that different persons work on it...

[Lenchik]

It is also useful for standard fields like langid and language. When you know for sure that will be only 2 or 3 languages in your *.bib database it is faster to select from dropdown list of options.

[lenhard]

@wilthan @olivierfruchart @Lenchik Content selectors are halfway back. Can you please try out the dev version available at http://builds.jabref.org/contentSelector/ (#2301) and see if it works for you (please use a backup of your bibfile). Please report if it works for you or if something breaks.

Currently, changes to the content selectors in the GUI (new keywords, etc.) require a restart of JabRef to become visible. If the current version works, it will go into JabRef 3.8, which is planned for release next friday. We would then fix the update of the UI later on.

[wilthan]

@lenhard
I tested the linked 64-bit dev verison and it worked as expected.
I

• opened an old file,
• changed the content with the predefined drop down,
• saved it and closed the application,
• reopened
• edited changes, saved and reopened again.

Thank you for getting that back into 3.8!

[Lenchik]

Win7 x64 and 64-bit version.
On existing bib-file it just add to existing field, without checking for already existing option.
That is how i got

language     = {russian, russian, english, russian, english},

Unfortunately, it worked that way also in previous versions (like 2.11.1).

Couldn't add more than one word in two steps, hitting return showed it in managing dialog but nothing added to dropdown list in database. But that way it worked in 2.11.1 version. Now it does not.
New selector, add new word, return, hit apply. Then go to main interface, see selector of one word, hit manage, add new word, return, hit apply - no changes to dropdown selector in main interface.

I will try to test 32 bit version on WinXP tomorrow

[lenhard]

@wilthan @Lenchik Thanks for your reports so far. Sounds like the feature is going to be merged in as-is.

@Lenchik I see your point regarding word duplications. However, after the experience of deleting the content selectors I am somewhat hesitant to change the functionality from what is has been before. Maybe there are users who want to have word duplicates in their fields and I would be breaking their workflow if I make the feature more restrictive?

The failure in the GUI update when managing selectors is known, but, as I wrote above, we will probably not get that fixed for 3.8 and will try to get it into a following version. At least, the basic feature seems to be back and working!

[koppor]

I would not expect duplicate words. As far as I understand, it was like that in JabRef 2.x, but changed in JabRef 3.x. Thus, only users of JabRef 3.x are affected by that change. Migrators from JabRef 2.x are not.

[lenhard]

@Lenchik @koppor Ok, turns out there is even a TODO comment in the code suggesting to implement the duplicate detection. Since this was an easy and localized change, I implemented it. A new build with duplicate detection should be available in a few minutes. @Lenchik Please have a try with that!

[Lenchik]

Seems like duplicate detection works OK now.

[lenhard]

The content selectors are merged into the main branch now and will be part of the 3.8 release.