Selecting a group impacts column width

[mlep]

JabRef 5.1--2020-07-13--6344401
Linux 4.9.0-12-amd64 amd64
Java 14.0.1

• Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

With "all entries" selected in the group panel, column width can be adjusted by grabbing the column separator and moving it sideways. This is the expected behavior.
But after selecting a subgroup and adjusting the width of a column, all the columns except one get squizzed.

Steps to reproduce the ABNORMAL behavior:

1. select a subgroup
2. adjust the width of a column.
   ==> on mouse button release, the column continue to get enlarged (or reduced depending on how you adjusted its width). The other columns get squizzed.

Another way to reproduce this bug:

1. with All entries displayed (selecting the group "all entries" or not), adjust the width of a column (here, it works as expected).
2. select a subgroup
   ==> the adjusted column starts to get enlarged (or reduced depending on how you adjusted its width). The other columns get squizzed.

Surprising and ... reproducible!

Nothing in the log.

Tip: the bug is absent in JabRef 5.1--2020-05-26--0d7156b, but present in JabRef 5.1--2020-06-09--595f085 .

Supplementary note:
In JabRef 5.1--2020-05-26--0d7156b (I have not tested with the other versions), switching between groups can lead to changes in the width of the columns (this is not systematic, but quite easy to reproduce). Compared to the issue described above, there is no need to change the column width at first. And it is not dynamic (i.e. the width of the columns do not start moving; they change instantaneously when switching between groups). Going back to the initial group does not re-establish the column width.
This may be a different bug, but it looks very related to the issue initially described. Since the initial issue is not present in JabRef 5.1--2020-05-26--0d7156b, it means the situation got worse afterwards.
Reproduced with the file https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/jabref-authors.bib

[mlep]

@koppor @Siedlerchr @tobiasdiez
I have noticed that you are getting ready to release version 5.1 of JabRef.
I want to attract your attention on the present issue: if other users have the same issue, that will block them from using version 5.1.

[koppor]

@mlep Could you make a video using https://www.loom.com/?

[mlep]

Here it is:

JabRef 5.1--2020-08-03--f6404b4
Linux 4.9.0-13-amd64 amd64
Java 14.0.2

[mlep]

I have tried to narrow it down.
To reproduce the bug, it seems you need to have 3 opened files (and the groups of one of the files must be different from the others (this later condition being quite common in real life, right?).

Let's play with the file https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/jabref-authors.bib

1. In a directory, copy jabref-authors.bib into jabref-authors2.bib, jabref-authors3.bib and jabref-authors-mod.bib
2. In jabref-authors-mod.bib replace "For teaching" by "For fun".
3. In JabRef, open jabref-authors.bib, jabref-authors2.bib, jabref-authors3.bib; and play with the column width, groups, and switch between files. Nothing abnormal happens.
4. close jabref-authors3.bib and open jabref-authors-mod.bib
   In jabref-authors-mod.bib, select the group "For fun". ==> the columns collapse

If only 2 files (including jabref-authors-mod.bib) are opened, no abnormal behavior.

[mlep]

Note: the 3 users reporting column shrinkage are using Linux

[alito21]

Note: the 3 users reporting column shrinkage are using Linux

I am experiencing the same problem under Windows 10.

[calixtus]

Bug seems depend on the SmartConstrainedResizePolicy. Tried with TableView.CONSTRAINED_RESIZE_POLICY and the bug did not occur. Workaround is by disabling "fit table horizontally on screen".

Will think about this one. Maybe this will require a more general solution...

[Blubbaa]

Had the same bug on

JabRef 5.1--2020-08-30--e023aa0
Windows 10 10.0 amd64 
Java 14.0.2

Workaround by disabling the setting under "entry table -> fit table horizontally on screen" worked!

[mlep]

Note: I am experiencing the same behavior with only 2 opened files, but this is rare (and I have not found how to reproduce it yet)
@calixtus Thanks for the work-around!

[koppor]

The underlying discussion is #967.

We seem to have a cool initial implementation done using the ResizePolicy. See #967 (comment).

In short the idea of #967:

• Columns have optimal width
• Sum of widhts matches window size
• Let this width be optX

There is a column min column width and thus a min window width. Let this be "minoptx".

If window size is increased, column size increases.
If window size decreases below optx, the column widht are decreased until minoptx is reached. Below minoptx, there is a scroll bar added.

Maybe, we did not use minoptx, but only optX.

The idea is refined in #967

• ability to define a minimal width for each column
• ability to define that a column should not be scaled
• automatic sizing of the table:
  • Each column should have at least its minimal size - if the space is not sufficient, a horizontal scrollbar should be used.
  • Columns with fixed size should use those fixed sizes
  • If there is additional space left the remaining columns could be broadend to use this space.

[koppor]

Hint: https://github.com/edvin/tornadofx/wiki/TableView-SmartResize

[mlep]

I cannot reproduce this bug anymore in JabRef 5.3--2021-03-11--8bb7668 (https://builds.jabref.org/master/)
@Blubbaa and @alito21: could you confirm?

Solved by PR #7507?

[Blubbaa]

Can confirm, I am not able to reproduce on

JabRef 5.3--2021-03-11--8bb7668
Windows 10 10.0 amd64 
Java 14.0.2 
JavaFX 16+8

Behaviour with "Fit table horizontally to screen" option also feels intuitive and normal.