Branch in the works: Config Confusion

Changing PyRoom configuration at runtime is quite complicated, at the moment. While our configuration file is quite simple and easy to use, PyRoom at runtime makes use of at least three different ways of using configuration files. It works, but there's a lot of unnecessary passing around of configuration objects and not everything those contain is configuration. Some objects also contain runtime state data, such as PyRoom's absolute path, which it needs for theme loading, etc.

Our current configuration methods

• Config file
  Our configuration file, pyroom.conf is kept in an instance of ConfigParser and accessible to most modules (not all) and can be manipulated directly.


• pyroom_conf
  When starting PyRoom, this instance of preferences.PyroomConfig() is created and (some) entries from our configuration file are being set as attributes. This objects is passed around to other modules - but, again, not to all.


• Preferences()
  This is actually our GUI class for the preferences dialog. Some settings are held there, too. This is not actually passed around the programme at all, but it's used internally when changing preferences and applying the results.

Applying of configuration changes is somewhat complicated, too. Since most of our programme is GUI, most of the settings used apply instantly visible to the user, too. But there's different ways to this, too. Some functions that change configuration apply the settings by themselves and change the settings only in their own place. Sparsely, the same settings exist in different places, too and are not affected by the configuration change, which led to trouble in the past. Other functions, though, set configuration settings in the config file and run apply_theme(), which reads from configuration and pyroom_conf to apply the settings found there, ignoring aforementioned "invisible" settings in the process.

Saving of configuration is a different beast, too. Since it's always hard to tell where exactly settings and states reside, it's hard to gather those for persistent storage in the configuration or theme files.

What's about to change

I've created a new module globals, which keeps two dictionaries: state and config. The new globals module is available to all other modules and is intended as the only method of configuration and state keeping. config, of course, is backed by ConfigParser and can be changed from everywhere. Settings that change the GUI can be applied by GUI().apply_theme() then. state, however, keeps runtime data, such as if GNOME default fonts are available, paths to configuration, themes, etc and other things that don't need to be saved to the configuration file.