4.0 groups view: no difference between keyword groups and normal one's

[buhtz]

Using 4.0 stable with Windows 10.

In 3.8. groups created by keywords where written in italic. But with 4.0 they are not.
I can see no difference (in the font face, size, ...) between normal groups and keyword groups.

This should be differed by default. e.g. with font, icon color, what ever.

[tobiasdiez]

Why do you need to know if a group is a keyword or an explicit (or search)?
I could imagine that we add this information as a tooltip. Is this enough?

[buhtz]

Interesting question - really! I think I am habitual (correct word here?) with it because JabRef 3.8 made a difference.

JabRef 4 has an icon for each group. Color and symbol can be modified by the user, right? Maybe there could be different default color or symbol for normal or keyword groups.

And the settings could have an entry "Use different default color/symbol for keyword groups" or something like that.

[tobiasdiez]

Yes, with new shiny things also some of the old features get changed ✈️ . I thought a lot about this question when redesigning the group interface and I just couldn't come up with a use case when the information about the kind of group is needed.

So yes, we can implement to show the type as a tooltip, or change the icon as you propose. But for all of this is, we have to put in development time - and "3.8 has it, so I want it back" is honestly not a good enough justification. So I would propose to close this issue unless you (or somebody else) puts forward a good use case.

Sorry for being a bit harsh here (and in some other issues) recently. We are currently swimming in a sea of "nice to have, but actually not that important"-issues and the organizational overhead is getting larger and larger (to the extend that we just manage issues instead of having the time to actually implement the bigger ones).

[AEgit]

I guess one use case could be that you want to differentiate how reliable your groups are: When you manually assign your entries to a group, you probably (hopefully :D) know, what you are doing, i. e. this is a reliably group assignment: if you quickly search through the group entries of a manual group, you will only get entries, that definitely should be there (according to your expert opinion).

Keyword and/or search groups, on the other hand, provide (semi-)automated groups. They may or may not contain all the items you would expect in a group, depending on how reliable your keywords/search translate into the grouping you expect (e.g., you set up a search for a certain word and it happens to be part of the abstract of an item, although the item itself clearly does not belong to the grouping you have in mind).

Having said all of this, I personally I'm not affected by this issue, as I'm not using keyword or search-based groups at all, but only manual ones (for the reasons reported above). As long as there's no user, that encounters these issues, I guess it is ok to ignore this problem. As you say, there are probably more important issues currently to address (maybe the performance-related ones, if I'm allowed to be selfish :D: #2852 and #3175)

[tobiasdiez]

Closing this issue due to inactivity 💤
Please reopen the issue with additional information if the problem persists.