Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement better scaling of main table showing entries #7181

Closed
wants to merge 37 commits into from
Closed

Conversation

koppor
Copy link
Member

@koppor koppor commented Dec 12, 2020

Fixes #967 so that resizing works "naturally".

Fixes #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 #6690 because of #7180

  • Change in CHANGELOG.md described (if applicable)
  • Tests created for changes (if applicable)
  • 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.

Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
@tobiasdiez
Copy link
Member

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.)

@tobiasdiez tobiasdiez added the status: changes required Pull requests that are not yet complete label Dec 13, 2020
@koppor
Copy link
Member Author

koppor commented Dec 14, 2020

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.

grafik

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
Copy link
Member Author

koppor commented Dec 14, 2020

Windows Explorer:

grafik

grafik

Double click should set the optimum width:

grafik

koppor and others added 2 commits December 14, 2020 20:32
- Remove preferences
- Remove MainTablePreferences (and migrate left-overs into ColumnPreferences)
- Fix name of "Show dedicated file columns" (instead of "Show extra columns")

Co-authored-by: Carl Christian Snethlage <50491877+calixtus@users.noreply.github.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
@koppor
Copy link
Member Author

koppor commented Dec 14, 2020

DevCall decision:

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

@tobiasdiez
Copy link
Member

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 and others added 2 commits December 17, 2020 20:27
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
@koppor
Copy link
Member Author

koppor commented Dec 17, 2020

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 koppor removed the status: changes required Pull requests that are not yet complete label Dec 17, 2020
Copy link
Member

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the update. Looks way better now. (And yes I like to keep useful code ;-) ).

I think I've found a few cases where the new column calculation doesn't work as expected. It would be very useful to have unit tests covering a few different scenarios. This would also give more confidence in the changes, also in the future (because I'm pretty sure we will miss some edge cases - the resize thing is really complicated sadly).
Here is a blueprint for a test: https://github.com/openjdk/jfx/blob/a128952b834fc57934c088aff1e024706dab2c5a/modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java#L1948-L1978

if (mainTablePreferences.getResizeColumnsToFit()) {
this.setColumnResizePolicy(new SmartConstrainedResizePolicy());
}
this.setColumnResizePolicy(new SmartConstrainedResizePolicy());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the if check should still be there, since otherwise the checkbox in the preferences doesn't do anything, right?

Copy link
Member Author

@koppor koppor Dec 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We removed the preference option completely - since this was a hidden feature. That should have been a visible toggle button and not hidden in the preferences.

Moreover #967 said that there should be a single behavior without the need of a configuration flat. We discussed it in length back then - and the implementors think, this is still a good thing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We added a guard to really cover both cases

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you don't want to give users the option for the infinite-column behavior that you were supporting above? I don't see any harm in still having the checkbox. But since I don't want to argue again for keeping code while you want to remove it, removing is also fine with me ;-)

newSize = newWidth;
} else {
// The columns not explicitly resized by the user get the negative delta
newSize = col.getWidth() - share * deltaToApply;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this doesn't result in a consistent table width. Imagine having two columns, with initial preferred widths of 70/30 and a total table width of 100. Now the user extends the first column by 10, so deltaToApply = 10. The first column then indeed has size 80 (as expected) but the second one has newSize = 30 - 0.3 * 10 = 27 although it should be 20.

@tobiasdiez tobiasdiez added the status: changes required Pull requests that are not yet complete label Dec 18, 2020
koppor and others added 10 commits December 19, 2020 00:17
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
@koppor
Copy link
Member Author

koppor commented Dec 21, 2020

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

grafik

koppor and others added 6 commits January 6, 2021 16:55
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
@koppor
Copy link
Member Author

koppor commented Jan 18, 2021

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
Copy link
Member Author

koppor commented Feb 1, 2021

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 Implement better scaling of main table showing entries #7181 (comment)
  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)

Copy link
Member

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, it would still be good if you could at least add some basic tests.

Hopefuly this shouldn't be too hard. Create a table, with a fixed width. Then call the reize policy and verify the result.

</Console>
<GuiAppender name="GuiLogger"/>
<OurApplicationInsightsAppender name="applicationInsightsAppender"/>
<File name="FILE" fileName="jabref.log">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes here probably need to be reverted, right?

/**
* SIDE EFFECT: Stores computed desired width if not present in HashMap. This leads to a constant desired width.
*/
private Double getDesiredColumnWidth(TableColumn column) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then rename to computeDesiredWidth

# Conflicts:
#	src/main/java/org/jabref/gui/maintable/MainTable.java
#	src/main/java/org/jabref/gui/preferences/table/TableTabViewModel.java
@calixtus
Copy link
Member

calixtus commented Feb 6, 2021

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.
    grafik
  • 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.
    grafik
  • After closing an reopening JabRef stored column widths are not reloaded

@calixtus
Copy link
Member

calixtus commented Feb 6, 2021

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

@koppor koppor mentioned this pull request Feb 7, 2021
5 tasks
@koppor
Copy link
Member Author

koppor commented Feb 7, 2021

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

* 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)
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
Copy link
Member

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

BindingsHelper.bindBidirectional(
this.widthProperty(),
model.widthProperty(),
value -> this.setPrefWidth(model.widthProperty().getValue()),
value -> model.widthProperty().setValue(this.getWidth()));

@calixtus
Copy link
Member

Dev-Call decision: restore last state

Needed to add "preferences.getColumnPreferences().isDedicatedFileColumnsEnabled()))" to PersitenceVisualStateTable.java

# Conflicts:
#	docs/adr/0016-mutable-preferences-objects.md
#	src/main/java/org/jabref/gui/maintable/PersistenceVisualStateTable.java
#	src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
#	src/main/resources/l10n/JabRef_en.properties
@koppor koppor self-assigned this Nov 14, 2021
@Siedlerchr
Copy link
Member

Siedlerchr commented Sep 13, 2022

@koppor
Copy link
Member Author

koppor commented May 7, 2023

I didn't have the time to finish it. Moving to koppor to reduce the number of PRs here. koppor#644

@koppor koppor closed this May 7, 2023
@koppor koppor deleted the fix-967 branch October 24, 2023 23:23
@koppor koppor mentioned this pull request Oct 24, 2023
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintable status: changes required Pull requests that are not yet complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Selecting a group impacts column width Better scaling of main table showing entries
5 participants