Implement better scaling of main table showing entries

[koppor]

trafficstars

Fixes #967 so that resizing works "naturally".

Fixes https://github.com/JabRef/jabref/issues/6690

~~The only missing thing is following:~~

~~If there is additional space left the remaining columns could be broadend to use this space.~~

~~This is future work. Proposal: Additional button doing this "magic". Thus, the user has control when other than the current column should be resized.~~

~~With the current implementation, JabRef is consistent with LibreOffice Calc's behavior (and other table calculation tools).~~

~~Still open: We could not reproduce https://github.com/JabRef/jabref/issues/6690 because of https://github.com/JabRef/jabref/issues/7180~~

• [x] Change in CHANGELOG.md described (if applicable)
• [ ] Tests created for changes (if applicable)
• [x] Manually tested changed features in running JabRef (always required)
• [ ] Screenshots added in PR description (for UI changes)
• [ ] Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[tobiasdiez]

I think what you implemented was already possible before by unchecking "Entry table > Fit table horizontally on screen" in the preferences (except if I misunderstood what you were trying to do).

(Also I think one shouldn't take calculation programs as inspiration since they usually have the concept of infinitely many columns.)

[koppor]

I think what you implemented was already possible before by unchecking "Entry table > Fit table horizontally on screen" in the preferences (except if I misunderstood what you were trying to do).

Not quite:

We implemented minimum width:

(shown in the dev call)

The "Fit table horitzontally on screen" is broken:

https://www.loom.com/share/70a2a976a5164619a03ceaa150ef2cdf

• Columns can be shrunk until they are not visible anymore
• Columns on the right "jump" while moving.

We are still thinking how to proceed. In my view, a "magic alignment button" setting an "optimal" cell width and then the user can adjust the widths manually is a least WTF than the current system.

For sure, we could work on something more "intelligent". I am not sure about the user experience if we are the only tool doing that way.

(Also I think one shouldn't take calculation programs as inspiration since they usually have the concept of infinitely many columns.)

Nevertheless, there JabRef typically has 15 columns.

The only tool I know with more than 10 columns is a spreadsheet application. Regarding the "Ewartungskonformität" (DIN 66234 Teil 8), this is the only thing raising expectations. Not sure whether other users also know spread sheet applications. However, I would guess so.

[koppor]

Windows Explorer:

Double click should set the optimum width:

[koppor]

DevCall decision:

Merge and work on column resizing afterwards. Probably with the magic button as in Windows Explorer.

[tobiasdiez]

Well, the no-automatic-column-resizing strategy is the default one of JavaFX and can be enabled by unchecking the above checkbox. So no code changes required for this.

While I agree that the smart resizing policy has some flaws, it was working relatively well (for me and many users).

[koppor]

Is this really the first time, I want to delete code and @tobiasdiez wants to keep it? 😇

@DominikVoigt and I worked hard to keep the smart resize. Here it is, freshly implemented in a (hopefully) smart way. Tested locally. Enjoyed it.

[koppor]

We had some WTF moments with minwidth 10, 29. We tried with 80:

[tobiasdiez]

I think, 10 or 15 is fine. You knows what our users put in their columns. It also makes it possible to temporarily shrink a column because it's not important for the task at hand...

[koppor]

We hit https://stackoverflow.com/a/47860355/873282. @koppor @DominikVoigt : Look at #7209. Should be easy

Expected behavior: double click: "optimal" column width. Iterate on content an choose the maximum content length as prefWidth.

[koppor]

We proceed as follows:

1. @calixtus resolves merge conflicts
2. Manual test of new system
3. Merge
4. Tests will come as follow up (otherwise, this won't happen until August 2021)
5. The issue with double click on a column leading to a wrong resize will be fixed later https://github.com/JabRef/jabref/pull/7181#issuecomment-762433799
6. Right-click on table column headers will enable "fixed" columns which should improve the UX even more
7. Right-click on table column will allow to enable standard resize policy again (which has the effect that enlarging a column does not shrink others). This re-introduces the standard-behavior of windows explorer
8. Right-lock on table column will offer "reaarange all columns" (because when changing from windows explorer policy to smart resize policy could lead to bad column widths)

[calixtus]

After a little bit testing, I made those observations:

• Minimal column width is too large: my year column is three times to big at minimum size.
• Contraintuitive behaviour: if I change the width of a column, the column border is not on the same x position as my mouse cursor is. The mouse cursor seems to move in-proportionally more than the column border.
• After closing an reopening JabRef stored column widths are not reloaded

[calixtus]

I fixed the merge conflicts as promised, but I believe, there are probably more cleanups to do...

[koppor]

After a little bit testing, I made those observations:

* Minimal column width is too large: my year column is three times to big at minimum size.

Depends on the other columns and the other columns. We decided not to add a fixed width to the year column. We hope for a context menu to have the year column fixed. IMHO 99% the users will use the fixed width, only some non-mainstream research will use more than 4 digits for a year

* Contraintuitive behaviour: if I change the width of a column, the column border is not on the same x position as my mouse cursor is. The mouse cursor seems to move in-proportionally more than the column border.

We know that. At first, it also seemed to be counter-intuitive. Later, we liked it somehow (and hoped for some feedback). -- The only possibility is to change the behavior that only columns right of the current column are resized. Maybe, this is the way to go.

* After closing an reopening JabRef stored column widths are not reloaded

Works as designed. See https://github.com/JabRef/jabref/blob/286e7f9434c681d8b5c413a619859b4b2a62154c/src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java#L66 for a reasoning.

I repeat it here

Initial table rendering

Decision to take: a) Use last setting or b) rerender with desired widths. We opt for b), because we assume that user-configuration of desired widths is easy. This leads to I3 being inconsistent to RWS2 (there is no previous width in I3).

[tobiasdiez]

Restoring the last column widths works currently and is not something that should be controlled by the resize policy. My guess is that https://github.com/JabRef/jabref/pull/7181/files#diff-535037ff480247bb2ecacf90ae5281974308e819eb2c3eed6b5cb15931a077caR122-R125 is overwriting https://github.com/JabRef/jabref/blob/e66f5be7d82c7a7618fe327fe958ec57a25ea598/src/main/java/org/jabref/gui/maintable/columns/MainTableColumn.java#L17-L21

[calixtus]

Dev-Call decision: restore last state

[Siedlerchr]

Related https://github.com/openjdk/jfx/pull/897

https://bugs.openjdk.org/browse/JDK-8293119

[koppor]

I didn't have the time to finish it. Moving to koppor to reduce the number of PRs here. https://github.com/koppor/jabref/pull/644