-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Conversation
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
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.) |
src/main/java/org/jabref/gui/maintable/MainTableColumnFactory.java
Outdated
Show resolved
Hide resolved
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
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.
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. |
- 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>
DevCall decision: Merge and work on column resizing afterwards. Probably with the magic button as in Windows Explorer. |
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). |
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
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. |
There was a problem hiding this 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()); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 ;-)
src/main/java/org/jabref/gui/maintable/MainTableColumnFactory.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/MainTableColumnFactory.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
src/main/java/org/jabref/gui/maintable/SmartConstrainedResizePolicy.java
Outdated
Show resolved
Hide resolved
newSize = newWidth; | ||
} else { | ||
// The columns not explicitly resized by the user get the negative delta | ||
newSize = col.getWidth() - share * deltaToApply; |
There was a problem hiding this comment.
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
.
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>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
Co-authored-by: Dominik Voigt <dominik.ingo.voigt@gmail.com>
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. |
We proceed as follows:
|
There was a problem hiding this 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"> |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
I fixed the merge conflicts as promised, but I believe, there are probably more cleanups to do... |
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
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.
Works as designed. See
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). |
Restoring the last column widths works currently and is not something that should be controlled by the resize policy. jabref/src/main/java/org/jabref/gui/maintable/columns/MainTableColumn.java Lines 17 to 21 in e66f5be
|
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
I didn't have the time to finish it. Moving to koppor to reduce the number of PRs here. koppor#644 |
Fixes #967 so that resizing works "naturally".
Fixes #6690
The only missing thing is following: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