Better scaling of main table showing entries

[matthiasgeiger]

The current behavior of the entry main table is rather weird in my opinion:

Generally there are two different options available:

1. Table is always using the full width of the JabRef window
2. Table is using fixed widths for each column - if the space is not enough there is a horizontal scrollbar - if there is too much space parts are simply empty.

It is possible to switch between those two behaviors by changing the preferences in the tab "Entry Table" -> "Fit table horizontally on screen".

What is the problem with the current solution?
I think "fit horizontally" is a sensible default, as free/empty space after all table columns does not make any sense - and normally a horizontal scrollbar is not wished by the users, too.
However, the current implementation has some drawbacks:
If a single column is resized all other columns are resized, too (to fill the gap, or to create the needed space) - this makes it rather hard to adjust the column width to your preferred style (e.g., year should be just big enough to show all 4 digit year numbers).
And: After resizing the JabRef window all adjustments are just gone...

It is already possible to define column width in the preferences (-> "Entry table columns") - but these column widths are only used, if "fit table horizontally" is not active.

In my opinion the best solution would be:

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

E.g., all special columns, the # column, entrytype and year have a fixed width - title, author/editor and journal are dynamic and use the remaing space in the table...

Any remarks to this concept? Do you propose another solution?

Problem is: I'm not quite sure whether Swing does actually support this behavior out of the box as it is a mixture between fixed widths and automatic scaling to avoid horizontal scrollbars... If this is too hard to implement, waiting for the JavaFX migration might be an option. However, regarding JavaFX I don't have any idea whether and how this can be realized...

[simonharrer]

👍 for implementing this now in Swing.

[oscargus]

Related to this is to add support for properties for each field. Table column scaling is one such property, others are sort order (e.g. numeric), alignment, which special field editors should be added etc (for example, right now most of the time the code check if the field is "author" or "editor", but in Biblatex there are quite a few more related fields which should be handled the same way and it would be nice to be able to add a property to the field that it contains names, rather than adding if-statements for all possible fields).

Right now, it is possible to add one field editor to each field and set it to numeric sorting. However, this should ideally be generalized.

I'm not saying that it is required to solve this, but it might be a good idea to think about this as well.

[oscargus]

Just wanted to point out that there is a ColumnWidthDialog which is currently unused. Not sure if it has been discussed if it should be removed or reused.

[lenhard]

Now that time has passed, it seems that this is going to be solved with JavaFX migration.

[lenhard]

The migration of the maintable to JavaFX is now underway: #3621

We could revisit this issue at some point and see how well the new version scales. With the newer framework, hopefully there are some scaling improvements out of the box.

[tobiasdiez]

In principle, with JavaFX it is now easy to customize the resize behavior. We just have to create our own ResizePolicy, see e3515e9#diff-a2536d932f2823d0965d7d1dcdaf497c for a very basic start.

A word of warning: coming up with a nice algorithm is however not as easy as it appears on first though. First of all, there many variables that influence the column width (padding, table grid on/off, vertical scrollbar, ...). Secondly, we have to decide a few things: a) how do you handle the new space when a column is resized b) how to distribute the remaining space after the fixed-size columns (equally, by preferred width, by ?). One should have a look at the two built-in resize policies and at https://github.com/edvin/tornadofx/wiki/TableView-SmartResize to get an impression of the complexity.