Prefs.xml file doesn't get updated when user closes the app

[mohammed faizaan]

USE CASE: WHAT DO YOU WANT TO DO?

make use of Prefs.xml file

STEPS TO REPRODUCE AN ISSUE

1. Open Treeview3 with an existing prefs.xml file in the same folder (TreewView3 does not make use of this Prefs.xml file, rather gets the user preferences from the windows registry)
2. Just after the user preferences are loaded into RAM, they are written into the file prefs.xml
3. Close TreeView3 (note that the prefs.xml file does not update with the latest changes. for example, any new file added to the recently opened files does not appear)
4. Reset/Clear old preferences (note that the prefs.xml file is not deleted)

CURRENT BEHAVIOR

I do not know the expected behavior and usage of prefs.xml file. Right now, we are not actively using the prefs.xml file, rather performing CRUD operations on the windows registry preferences.

EXPECTED BEHAVIOR

Make correct use of prefs.xml file

DEVELOPERS ONLY SECTION SUGGESTED CHANGE (Pseudocode optional)

1. Update prefs.xml file when user closes the app
2. delete? prefs.xml file when user resets Preferences from the app
3. Handle correctly whether the preference should be loaded from windows registry or from prefs.xml file, when the user opens the app

FILES AFFECTED (where the changes will be implemented) - developers only

1. LinkedViewApp.java
2. TVController.java
3. TreeViewApp.java

LEVEL OF EFFORT - developers only

minor

COMMENTS

I do not know the expected usage of prefs.xml file. Please comment on how we can improve the intuitiveness of app preferences. Once the exact usage and behavior of this functionality is discussed, someone can work on this task.

[Robert Leach]

Is prefs.xml where the TreeView settings are maintained? I've never worked on any code that uses that. If it is though, then it's possible this issue may be related to a couple other issues such as issue #154. Other preferences updating issues such as window size & position, last open file, the recently opened files, have been linked in the past to the method in which the app was quit.

I know that for issue #154, I resolved the issue by updating the preferences upon the change of those settings whereas before, they were only saved upon quit - and only when the app quit operation was initiated via the window close button. It was not saving via the keyboard shortcut (command-q) or via the menu quit selection.

Chris looked into this and determined that hooks to do operations on quitting via those methods would be possible only after packaging with something like gradle (sp?).

So is this the same issue? If you quit the app using the app window's close button, does the prefs.xml file get properly updated?

[Christopher Keil]

The prefs.xml file is not actively used and shouldn't be. It exists only for debugging reasons and to understand how Preferences nodes are arranged. The reason why it is updated when starting the app is that this point is when I happen to write it. The file is created when starting TreeView. It just reflects the structure of the Preferences nodes stored in the system.

The writing lines to create the file are found in the constructor of TreeViewApp.java:

// Generate an XML file of the Preferences at this point, so it
        // can be viewed and analyzed.
        try {
            FileOutputStream fos = new FileOutputStream("prefs.xml");
            globalConfig.exportSubtree(fos);
            fos.close();

            final ToolTipManager ttm = ToolTipManager.sharedInstance();
            ttm.setEnabled(true);

        } catch (final IOException | BackingStoreException e1) {
            LogBuffer.logException(e1);
            LogBuffer.println("Could not export preferences XML "
                    + "file for viewing.");
        }

If you want the prefs.xml "properly updated" then move this exact code to its own function such as

writePrefsXML()

(could be in any class) and call this method when the application is exited.

By the way, here is some documentation on the Preferences API: https://docs.oracle.com/javase/7/docs/api/java/util/prefs/Preferences.html

@hepcat72 Did you happen to add the

ToolTipManager

code here? I don't remember this at all...

[Robert Leach]

Removing milestone: Settings (automated comment)

[Robert Leach]

I did not add the tooltip manager code. I checked out the source and tried the "blame" button and it shows that the only person who has touched that line in the file history is you... though I don't know if that history is complete...

[Christopher Keil]

I marked this as invalid because there is no "correct use" for prefs.xml. We should disable the code for production deployments, so people don't get confused.

It exists for debugging reasons only, but we can certainly move the code to generate the file to the point where the app closes.

The Windows registry changes (and files generated for Unix-like system) are the way the Java Preferences API works.