Chapter 3 Preferences for a GUI Application
3.1 Introduction: GUI Preferences
Many applications expose their configuration files to users. If a user wishes to reconfigure such an application, then he or she uses a text editor to modify its configuration file. That approach is common for applications that do not have a graphical user interface (GUI). However, in GUI-based applications, it is common for configuration changes to be made through the GUI itself rather than through an external text editor.
For example, when using a GUI application on Microsoft Windows, you can typically use the Tools →Options… menu item to open a tabbed dialogue box that enables you to modify the application’s configuration. The equivalent menu item in GUI applications running on UNIX-based operating systems is often Edit →Preferences.
3.2 Persisting Preferences
When you make changes to the “preferences” or “options” of a GUI-based application, the application saves those changes to a (hidden) configuration file, so that if you quit the application and restart it, then the application can reload the most recent set of configuration values. A GUI application on Microsoft Windows typically uses the Windows Registry as its “hidden configuration file”. A GUI application running on UNIX might use a Java properties file or an XML file for the same purpose.
3.3 Using Config4* to Persist Preferences
You may be wondering if, when developing a GUI application, you could use Config4* to store the application’s preferences/options. Unfortunately, I do not know the answer to that. This is because I do not have much experience with developing GUI applications, and hence cannot offer knowledgeable advice.
I suspect that most GUI applications are built with the aid of a framework library that simplifies the development of such applications. For all I know, such framework libraries might automate the saving and loading of preferences/options data. If that is the case, then those framework libraries are probably programmed to use, say, the Windows Registry or an XML file. If this assumption is correct, then it will probably be easier for you to use that provided functionality rather than try to modify the framework library (or work around it) to use a Config4* file instead.
However, perhaps some readers will be building a GUI application without the aid of such a framework library. Or perhaps some readers want to implement a new framework library that simplifies the development of GUI applications. If such readers want to consider using Config4*, then I offer the following advice:
- Read a Config4* configuration file in the usual way, that is, by creating an empty Configuration object and then calling parse(). However, also use fallback configuration so that a GUI application can work “out of the box”.
- When the user modifies some of the preferences/options via the GUI, call cfg.insertString() or cfg.insertList() to insert (or update) the corresponding entries in the configuration object. Then call cfg.dump() to get a textual representation of all the configuration information, and write this to the application’s hidden configuration file.
- You might want to read the discussion of the dump command in the The config4cpp and config4j Utilities chapter of the Config4* Getting Started Guide. That discussion explains why reading a Config4* file and then dumping it back again does not preserve adaptable configuration that had been present in the original file. Keep that limitation in mind when designing your framework library or GUI application.