Do not resize main table columns in search dialog window

[Siedlerchr]

Fixes part of #8054

Add flag if listeners should be used.

The only drawback is that it's impossible to store the dialog colunn size.
Edit// I thought about a possible way but this is currently not really possible without duplicating all the code

- [ ] Change in CHANGELOG.md described in a way that is understandable for the average user (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, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[calixtus]

I'm not sure if the binding to the columnmodel is the right place to do this. I'm home tomorrow evening and will take a deeper look.

[calixtus]

I need some more time to dig into this, sorry, i need to find the connection between the maintable columns and the search table columns. The filters, that will be disabled with this pr are connecting the table with the columnmodel. Somehow this is shared between both, but should not be.

[tobiasdiez]

I don't see anything wrong with setting up the binding...I would say it's the job of the model to save or not save the updated width to the preferences.

[calixtus]

Answers just 4 minutes apart. Must have been some kind of though transmission 😁

[calixtus]

Storing to the preferences is done in the PersistenceVisualStateTable class, which is only called from the MainTable class. But storing in the preferences is not the cause of the problem.
MainTable and SearchTable are sharing the same MainTableColumnModel, thats why the width is synced. Providing a fresh set of MainTableColumnModels should even make storing the widths of the SearchDialog table possible.

[Siedlerchr]

But in the end they are stored under the same preferences key and would still overwrite the main table ones, probably after a restart

[calixtus]

Let's not do the third step before the first.
Could be solved by injecting a proper subset of prefs or a flag.

But for now let's solve the synced widths problem

[calixtus]

Problem analysis: The MainTable and the SearchTable share the same MainTableColumnModel. The width of the actual columns is bound to that MainTableColumnModel. Instead of not using listeners in the MainTableColumnModel (which has nothing to do with the actual problem and should not be touched), the SearchDialog should get new MainTableColumnModels, independent of the MainTable. Best way to do this would probably to introduce a flag in the JabRefPreferences to provide a fresh copy of the ColumnPreferences instead of providing the cached version of it.

[calixtus]

A new set, because if you share the MainTableColumnModel, you will always have problems again, when you try to manipulate the SearchDialog, which then would always have effect again on the MainTable columns.

[Siedlerchr]

A new set, because if you share the MainTableColumnModel, you will always have problems again, when you try to manipulate the SearchDialog, which then would always have effect again on the MainTable columns.

jabref/src/main/java/org/jabref/gui/maintable/MainTableColumnFactory.java

Lines 79 to 84 in 476dc29

	public List<TableColumn<BibEntryTableViewModel, ?>> createColumns() {
	List<TableColumn<BibEntryTableViewModel, ?>> columns = new ArrayList<>();
	columnPreferences.getColumns().forEach(column -> {
	switch (column.getType()) {

So I think I understood it now. The preferences return the MainTableColumn model for each column, so in this factory wee need to provide a new MainTableColumnModl which has the same columns but is a different object. But I don't know there we should get that new object

[calixtus]

Yes. The columnpreferences are cached inside Jabrefpreferences. Should be somewhat easy to command jabrefpreferences to create a fresh set of MainTableColumnModels instead of using the existing one. Maybe it's best to introduce a new method: getSearchDialogColums(), which internally just copies the behaviour of getColumns but without caching. Would leave some space for later improvement (saving the column width of the SearchDialog columns ;-) )