Importing settings does not work completely! (Entry table and entry settings)

[NeymanDmitry]

JabRef version

Latest development branch build (please note build date below)

Operating system

GNU / Linux

Details on version and operating system

Ubuntu 24.04

Checked with the latest development build (copy version output from About dialog)

• [x] I made a backup of my libraries before testing the latest development version.
• [x] I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

When we need to transfer program settings to another computer with a similar operating system such as Ubuntu/Debian, we perform the following steps:

1. Open the program properties and export the settings to an .xml file.
2. Import this file into the program on another computer with a similar operating system.

As a result, when exporting to an .xml file, the latter contains all the settings. But when importing, the settings are not completely transferred. In particular, the Entry types and Entry table settings are not transferred.

JabRef 6.0-alpha.193 was used.

Appendix

...

Log File

Paste an excerpt of your log file here

[Siedlerchr]

I would appreciate it if you could provide the XML file you are trying to import.

[NeymanDmitry]

example.zip

[Siedlerchr]

In general this works, however, I think maybe your issue:

1. Import the preferences
2. Leave the Preference Dialog via Cancel and restart
3. => All the correct values are imported:

[NeymanDmitry]

I tried to exit the settings after import by using the Cancel button. It does work, but it's counterintuitive. Obviously before that, I used the Save button when leaving the Preference Dialog!

[HoussemNasri]

Thank you for bringing this up.

So our preference architecture is built on three layers:

1. The java.util.prefs.Preferences layer: which stores settings in XML format using standard Java APIs.
2. The JabRefGuiPreferences layer: which parses the XML into a more developer-friendly POJO format, making it easier to use by the view layer.
3. The PreferencesTab layer: which represents the state of the actual views in the preferences dialog UI. Things like checkbnox status, list view content, etc.

Obviously, synchronization needs to exist between the three layers.

On the code level, importing preferences calls two functions: java.util.prefs.Preferences#importPreferences and PreferencesTab#setValues.

The former updates layer 1, while the latter attempts to update layer 3, but it doesn't succeed because layer 3 gets its data from layer 2, which was not updated, so what layer 3 gets is outdated data.

Closing the dialog at this point by doing anything but clicking the save button and restarting JabRef should get you the expected preferences that you have imported because at startup JabRef reads from layer 1 (whch was uptodate when we closed JabRef) and initializes the other layers based on it.

However, clicking save would write OUTDATED data from layer 3 to layer 2, which will automatically (through binding) update layer 1, with again, outdated data.

Blue pill

We implement a workaround. These are a few suggestions:

• Close the dialog automatically once preferences are imported and of course show the 'you need to restart warning dialog' (my favorite).
• Pass a boolean to PreferenceTabs to disable saving preferences after user imports preferences.

Red pill This one needs much more discussion. We might need to pass a PreferenceProvider (an object that knows how to create the preference object and decides whether to return a cached one or create a new one when called) instead of the actual Preference object to views. This was; when PreferencesTab#setValues is called, the provider will provide it with the up-to-date preference state from layer 1.

---

I suggest we take the blue pill for now, marking this as a good first issue because it should be easy to handle and discuss the red pill solution more.

[ankamde]

/assign-me

[github-actions[bot]]

⚠️ Issue Already Assigned

Hi @ankamde, this issue is currently assigned to @calixtus.

[!NOTE] If no progress is made within 14 days, the issue will be automatically unassigned.

Options for contributors

• Wait for availability: The issue may become available if auto-unassigned
• Collaborate: You can ask the assignee if they want help
• Maintainer assistance: A maintainer can add you as co-assignee if appropriate

[koppor]

Work towards fixing this is made at https://github.com/JabRef/jabref/pull/13894.