A few issues with the new groups panel in version 4

[AEgit]

JabRef 4.0.0-dev--snapshot--2017-03-01--braces-checking-followup--488825af5

This ticket is supposed to mention a few problems with the implementation of the groups panel in the current development version 4 of JabRef.

I realized that saving a huge database (>10,000 entries) takes now much longer than with version 3.8.2 (database was saved nearly instantaneously), especially when the entry preview is open. Indeed, the usage of the CPU suddenly spikes to nearly 100% and it takes several seconds for JabRef to save the database. In the meantime it behaves as if JabRef had crashed. This might be related to some issues of the groups feature which I report below. Performance issues with version 4 have also been reported elsewhere: #2587 and #2588

Generally the implementation of the groups feature in JabRef 4 is:

• slower than the old one (especially when you try to save changes in your database while the entry preview is open - see above). Furthermore, the first time you try to expand "All entries" it takes a couple of seconds before the expanded groups are shown.
• does not allow to hide the number of entries (which might cause some performance issues on large databases): hit number is calculated async, thus there shouldn't be a performance problem
• cannot be opened with all subgroups expanded as default: fixed (expansion status will be kept across sessions)
• displays group titles with underscore, e.g. "Alpha_taxonomy" as "Alpha_(t)axonomy", i. e. brackets are added to the first character following the underscore: consequence of a known bug Latex2Unicode Formatter: Captial letters after an underscore are wrapped in braces #2664
• does not offer the same options that were available with the old group panel, when rightclicking onto one of the groups. E.g., the menu points
  • "Edit group": Add a few groups actions #2674
  • "Add group",
  • "Remove groups and subgroups"
  • "Remove group keep subgroups": Add a few groups actions #2674
  • "Remove subgroups": Add a few groups actions #2674
  • "Expand subtree": removed in Remove the following commands in the right-click menu of a group: #2697
  • "Collapse subtree": removed in Remove the following commands in the right-click menu of a group: #2697
  • "Move: Up, Down, Left, Right": removed in Remove the following commands in the right-click menu of a group: #2697
  • "Sort alphabetically"
  • "Assign entry selection to this group": Add a few groups actions #2674
  • "Assign entry selection exclusively to this group": removed
  • "Exclude entry selection from this group": Add a few groups actions #2674

don't appear to be available. Only "Add subgroups" appears to be available at the moment.

• The group settings
  • "Intersection": issue Allow selection of multiple groups #2786
  • "Union": issue Allow selection of multiple groups #2786
  • "Inverted": issue Allow selection of multiple groups #2786
  • "Edit group membership": edit mode was removed
  • "Gray out non-hits": moved to preferences Fix a few smaller group related things  #2705
  • "Hide non-hits": moved to preferences Fix a few smaller group related things  #2705
  • "Highlight overlapping groups": removed in Remove the following commands in the right-click menu of a group: #2697
  • "Show number of elements contained in each group" (see b)): not necessary
  • "Automatically assign new entry to selected groups": option moved to preferences

don't appear to be available at the moment.

• You cannot drag'n'drop an entry onto a group to assign it to that group (has already been reported here: Adding an entry to a group by dragging no longer possible #2590): Implemented in Add drag and drop for groups -> groups #2632
• You cannot drag'n'drop a group onto another group to assign it as the subgroup of the other group: implemented in Add drag and drop for groups -> groups #2632

[tobiasdiez]

In particular the performance of the filter is horrible: #1904 (comment).

Further things:

• Search case insensitive as suggested Implement #1904: filter groups #2588 (comment): fixed in Fix a few smaller group related things  #2705
• Rework add/edit group dialog (in particular, add a more user-friendly way to change icon + color) Is the subject of [WIP] Design ideas for group dialog #2643
• Context menu always visible as observed in Add icon + color and description to groups #2612: fixed in Fix a few smaller group related things  #2705
• Tooltip empty: Fixed in 92a5d23
• Automatically adding entries to selected group (when creating / importing) does not work. Reported in the forum. Issue: Automatic insertion of keyword according to group #2783.
• Resort groups by drag and drop as raised in nullpointer exception #2656 (comment). Issue: Allow resorting of groups using drag & drop #2785
• Main table view is not updated after the groups changed (e.g. an entry was assigned to the group): Add drag and drop for groups -> groups #2632 (comment). This is an old bug Main table non updated properly when newly assigning an article to a group #1903.

[bernhard-kleine]

JabRef 4.0.0-dev--snapshot--2017-03-17--master--44f666ed2
Windows 7 6.1 amd64
Java 1.8.0_121

Some issues with groups have already been solved. I miss one feature:

1. A group should be dragged between any two groups. At the moment you can drag a group to another group so that it becomes a subgroup of that group. I think it would be nice to move a group to the space between two other groups.
2. I also would like to be able to sort subgroups alphabetically.

[Siedlerchr]

I am just taking care of the sorting features.
@bernhard-kleine Please check out the branch:
http://builds.jabref.org/groupSorting/
Please report any errors/problems in the associated PR #2666

[bernhard-kleine]

Nice!

[koppor]

Regarding remove from all groups: The following interface should be improved:

[Siedlerchr]

Different SubGroups with the same name are considered the same group.
Assign an entry to group A\SubGroup it gets added to B\SubGroup, too.
Refs #2695

[buhtz]

I am not sure if this Issue is the correct place for this. I used the current snapshot (with OpenJDK).

It looks like that there is a problem while displaying the name of groups, when there are underlines _ in it. Please see entry_date here.

This groups is represtented in the bib file with that line
1 ExplicitGroup:_entry_date\;0\;;

This happens to all my groups with a _ in the name.

[Siedlerchr]

That issue is a problem with the unicode converter #2664

[buhtz]

Another case (is it ok if I post that here?):
I get this message on console and in the gui

12:43:44.776 [AWT-EventQueue-1] WARN org.jabref.logic.importer.OpenDatabase - Empty BibTeX key: N/A: "Euromaxx-Dein\_Freund,\_der\_Social... (Grouping may not work for this entry.)

In the console it is ok. But in the gui it makes no sense because the entry is well added to a static group. It doesn't matter if there is key or not. This is a bit to much "warning" for a normal user and could be checked. This message should only appear in the gui when there is no bibtex-key AND no group-entry.

[buhtz]

As remarked in this forum post I add notes here.

The topic is about that JabRef 4 modify the format of the bib file in a way that it is not backwards compatible.

The debug/console output of JabRef3.8.1 is not informative enough. There is no message about which bib-file is tried to open and if there is a problem with that.

The dev-snapshot reformated the bib-file in that way it wasn't backwards compatible. This is ok but should be done transparent and more communicative!

2a.
An extra backup (not the default bak-file) should be done automaticly if a bib-file is transformed that way. Name it e.g. myfile.bib.3.8.1.bak. In Tobias opinon such an extra backup "is not easily possible". I don't know the code but I don't agree because JabRef still create bak-files.

2b.
Such a transformation (including the name of the extra backup file) should be clear communicated to the user. A message dialog should be opened to inform that user about the transformation and that there is no way back (except with the extra backup file).

[matthiasgeiger]

Another small problem: Just adding an entry to a group (using either drag-and-drop, or the "add to group" dialog) does not mark the database as "dirty". Thus, it is not asked whether the database should be saved upon closing.

[AEgit]

By removing the options "Move: Up, Down, Left, Right" it is no longer possible in JabRef 4.0.0-dev--snapshot--2017-04-22--master--059f805e6 to freely position a group in the groups panel. By using drag'n'drop you can only assign one group as subgroup to another, but it is not possible anymore (or at least I don't know how) to change the position of one group relative to groups of the same level.
E.g.:
Group 1:

• Subgroup 1
• Subgroup 2
• Subgroup 3

Let's say we want Subgroup 2 to be above Subgroup 1 in the groups panel, like this:
Group 1:

• Subgroup 2
• Subgroup 1
• Subgroup 3

In the old version you could achieve that by using "Up" and "Down", which was actually quite tedious work (so I appreciate the idea to get rid of it) but at least it worked. Now, I don't know how I'm supposed to change the order of the subgroups.
It would be intuitive if you could just drag the subgroup to the respective place (without assigning it to another group) but this does not seem to work (?).

[Siedlerchr]

@AEgit This is achieved using drag and drop by moving the sub group over the parent group:

You have to drag a subgroup over its parent. The selected subgroup you move will be placed farthest down in the position:

We start with:

Group 1:

• Subgroup 1
• Subgroup 2
• Subgroup 3

Then you move SubGroup1 over the parent and you will get:

Group 1:

• Subgroup 2
• Subgroup 3
• Subgroup 1

Then you move SubGroup3 over the parent and you will get:

Group 1:

• Subgroup 2
• Subgroup 1
• Subgroup 3

[AEgit]

@Siedlerchr : Thank you very much for the explanation!
Hmmm, isn't this a bit incovenient? I mean, this is all right, if you are dealing with just 3 subgroups, but my database often contains 10 subgroups or more, and then moving one subgroup gets quite complicated. Is it possible to implement the drag'n'drop feature of groups so that you can actually directly move them to the desired position?

[bernhard-kleine]

If you have a complex tree, adding entries to a specific place in the tree using the move is (has been) much easier than pulling every subgroup onto the heading group. Not very reasonable.

[Siedlerchr]

I agree that this is a bit inconvenient. We will see how we can improve it.

[tobiasdiez]

As we approach a reasonable good state of the groups reimplementation, I extracted the remaining problems or suggestions to new separate issues. Please use them for more feedback.

[AEgit]

@tobiasdiez : What about the performance issues (see first post in this thread)? These are still present and a major problem with large databases. Should a new issue be created for that or should this issue report be kept open?

[AEgit]

Actually I take it back - the only performance issue that is left (as far as I can tell), is the groups search, which already has its respective issue report here: #2588

Thank you for your great work!