Skip to content

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

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

Open
2 tasks done
NeymanDmitry opened this issue Mar 9, 2025 · 6 comments
Open
2 tasks done
Assignees
Labels
Milestone

Comments

@NeymanDmitry
Copy link

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)

  • I made a backup of my libraries before testing the latest development version.
  • 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
@github-project-automation github-project-automation bot moved this to Normal priority in Prioritization Mar 9, 2025
@Siedlerchr Siedlerchr changed the title Importing settings does not work completely! Importing settings does not work completely! (Entry table and entry settings) Mar 9, 2025
@Siedlerchr
Copy link
Member

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

@NeymanDmitry
Copy link
Author

example.zip

@Siedlerchr Siedlerchr added this to the 6.0-beta milestone Mar 15, 2025
@Siedlerchr
Copy link
Member

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:
Image Image

@NeymanDmitry
Copy link
Author

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 HoussemNasri self-assigned this Apr 19, 2025
@HoussemNasri HoussemNasri added the status: has-workaround Bugs where a workaround exist label Apr 19, 2025
@HoussemNasri
Copy link
Member

HoussemNasri commented Apr 20, 2025

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.

@HoussemNasri HoussemNasri removed their assignment Apr 20, 2025
@HoussemNasri HoussemNasri added the good first issue An issue intended for project-newcomers. Varies in difficulty. label Apr 20, 2025
@github-project-automation github-project-automation bot moved this to Free to take in Good First Issues Apr 20, 2025
@calixtus calixtus self-assigned this May 12, 2025
@koppor koppor removed the good first issue An issue intended for project-newcomers. Varies in difficulty. label May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Normal priority
Development

No branches or pull requests

5 participants