Incorrect count entry number

[Ali96kz]

Steps to reproduce the behavior:

1. File -> (New Bibtex library) or (New Biblatex library)
2. Add some entry
   Number of entry will be 0.
   

[AEgit]

Is it always an incorrect number, or does this only happen the first time you assign a item to a new group?

I noticed this behaviour before, but as far as I remember you get the correct numbers of items contained in a group, if you save your database, then close JabRef and then reopen the database in JabRef.

This is still, obviously, a bug, but a less serious one, I guess - it is basically the updating process of the groups panel, that does not work properly (which I think is also responsible for some other issues we see with the groups panel).

[Siedlerchr]

Sometimes the number update if you switch to another db and then back again.

[CaptainDaVinci]

@Siedlerchr However, on switching to another library, group count shows count of previous library.

I am looking into this issue right now, what I have found is that when the database is changed, a new instance of the IntegerProperty hits is created each time [1]. And Text (representing GUI for the number of hits) is being bound to this newly created instance [2], therefore the binding does not prove useful here.

The Text should still be updated with the value of hits anyway, but it turns out that the binding of hits to Text is done before hits is updated. It is because of another binding [3] which internally triggers a callback to ViewModelTreeTableCellFactory.

This results in Text holding previous value of hits and not the current one.

When JabRef starts up there are some initial calls made which havehits initialized to 0, and Text binds to that, until database is changed.

[tobiasdiez]

Thanks for investigating this issue. This is how it is supposed to work:

• Whenever a library get's the focus, convert the group tree to a tree of GroupNodeViewModels.
  

  jabref/src/main/java/org/jabref/gui/groups/GroupTreeView.java

  Lines 108 to 113 in 6c61664

  	EasyBind.map(viewModel.rootGroupProperty(),
  	group -> new RecursiveTreeItem<>(
  	group,
  	GroupNodeViewModel::getChildren,
  	GroupNodeViewModel::expandedProperty,
  	viewModel.filterPredicateProperty())));

• Bind the value of the hit property to the text field
  

  jabref/src/main/java/org/jabref/gui/groups/GroupTreeView.java

  Line 137 in 6c61664

  text.textProperty().bind(group.getHits().asString());

• Whenever there are changes to the library, update the hit count (which should then propagate to the text label through the above binding)
  

  jabref/src/main/java/org/jabref/gui/groups/GroupNodeViewModel.java

  Lines 86 to 87 in 6c61664

  	// Register listener
  	databaseContext.getDatabase().getEntries().addListener(this::onDatabaseChanged);

  
  

  jabref/src/main/java/org/jabref/gui/groups/GroupNodeViewModel.java

  Lines 216 to 218 in 6c61664

  	private void onDatabaseChanged(ListChangeListener.Change<? extends BibEntry> change) {
  	calculateNumberOfMatches();
  	}

So it sound's reasonable that there is a problem with the binding of the text label to the correct hits property.

[samiyac]

@tobiasdiez I think the problem might actually be concerned with databaseContext.getDatabase().getEntries().addListener(this::onDatabaseChanged);
I added a print statement inside the function onDatabaseChanged and it didn't print anything after a few entries were added.
The problem is related to this: https://stackoverflow.com/questions/44341400/whats-the-purpose-of-fxcollections-unmodifiableobservablelist/
This would solve issue #4679.

However, I think this issue might have more to do with the group being utilized in the line text.textProperty().bind(group.getHits().asString()); is the older group. This causes value to not be set properly. But I think this happens only if the only group you have is All Entries.

[samiyac]

@tobiasdiez and @Siedlerchr Why do we have the All Entries group available when no library has been opened in JabRef? It doesn't seem to serve any function.

[tobiasdiez]

You are right the "All Entries group" should only be shown when there is an open library.

[stefan-kolb]

The value should also be updated if the library is closed which also does not happen right now.

[stefan-kolb]

See #3142. Will probably fix both of the issues.

[tobiasdiez]

This should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.

[AEgit]

JabRef 5.0-dev--snapshot--2019-09-16--master--1bec5efd3
Windows 10 10.0 amd64
Java 11.0.4-bellsoft

As far as I can tell, this issue appears to be fixed in the current developer version of JabRef. Thank you very much!

What I do note, however, is that assigning articles to new groups creates a massive CPU workload (always around 95%-100% CPU workload on a 6-core Core i7). This CPU workload takes several minutes to disappear. I do not know, however, whether this issue is related to the current fix or if it is just related to the general performance problems, that JabRef has at the moment (see #5071).

[AEgit]

Follow-up: Note also, that the group entry count number is updated immediately, when an item is assigned to a new group. But the colour indicating the group assignment is not. The colouring of the group affinities is only updated if you select another item in the main table or another group in the panel and then re-select the newly assigned item.
As you can see, this is not a major issue, but I wanted to report it (see also here: #3112 (comment)).

[tobiasdiez]

Thanks for the feedback. I'll try to improve the performance in the coming weeks but first I wanted to fix as much bugs as possible. Please open another issue for the coloring problem.

[AEgit]

I just realised that I had reported the colouring issue before. See here:
#3112

and (similar but not the same) here:
#2857

Thank you very much for your continuous work on JabRef!

[Siedlerchr]

@AEgit Did you encounter by chance this issue after the latest fix? #5327

[AEgit]

@Siedlerchr Sorry for taking so long. See my reply here: #5327 (comment)

No, I cannot reproduce the issue you reported.

[Siedlerchr]

Okay thanks for the info. Will test it again on another computer