Goals for preference management

Since preferences are required nearly across the board of applications, it would be nice for GE to provide some support for developers and users in terms of preferences management. To that end I have a set of goals that I think we should try to accomplish. These all come down to this:

Make it easy for users to...

1. find preferences from inside applications.
2. find preferences from outside applications.
3. interact with or change preferences.
4. edit preferences from inside applications.
5. edit preferences from outside applications.
6. manage multiple configurations of preferences.

Also, make it easy for developers to...

1. provide preferences. (this implies saving and loading)
2. provide a consistent preference interaction. (between their own apps, other third party apps, and system apps)
3. allow editing of preferences inside their application.
4. allow editing of preferences from outside their application.
5. manage multiple configurations of preferences.

These are an ambitious set of goals, in my humble opinion. However, I also believe that they are worth pursuing. Some of these goals matter less for particular applications than others, and some may matter not at all for some applications. It may certainly be overkill to support multiple configurations of your mouse settings, for example. However, multiple configurations of your system sounds could be reasonable. ("theme" anyone?) And different people need different configurations for different programs for different reasons.

I think accomplishing these goals will enhance the experience of BeOS for both developers and users.

Possible solution

It seems to me that the simplest way to address these goals goes along these lines:

• 1 file = 1 configuration
• configuration file is a standard format. possibilities:
  • flattened BMessage
  • variable=value text files
  • XML files
  • empty, attributed files
• a system bundled editor for standard format configuration files (possibly not necessary for text files, but recommended for XML files)
  • should provide a user experience very similar to the panel below
• a system provided panel for editing preferences from within an app
  • should make it easy for an application to know when a dialog item has changed (1 possibility: BMessage to provided BHandler, or default to app BLooper)
  • should probably provide a tree widget at the left
  • should probably provide a limited set of common buttons, and perhaps a facility to programmatically add more. (app request) buttons should be displayed below a changing viewport. buttons that affect only a panel's state should be placed within a border containing the viewport as well. actions that affect the entire dialog's state should be placed as buttons below both the tree widget (if present) and outside the border for the viewport, possibly divided from these by a horizontal bar. alternatively, dialog actions could be placed on a menu. new configuration, load, save configurations, etc. could naturally fit on a file menu, for example. for an example of this, look at an "open file" dialog or a "save as file" dialog. [I will try to provide images later]
  • could use add-ons to provide the interfaces for the changing part of the viewport (like ScreenSaver)
  • could allow saving of settings to a configuration file
  • could allow loading settings from a configuration file

Comments on standard configuration file options

Using straight text files of the variable=value variety has the benefit of familiarity. With comments they can be self-explanatory. They can be edited in any text editor. However, they have a number of drawbacks. There's no natural way to provide an interface for them aside from a list of variables and empty boxes for values. Unless it is put in the comments there's no way to tell the space of possible values for a variable. Even with information in the comments it is not difficult to set up an inconsistent set of values for variables. My opinion is that these files should be left in the past.

BMessages have a number of advantages. A number of applications already use BMessages. There are existing mechanisms for flattening and unflattening messages. BMessages can contain rich nested structure. It would be easy to put references to add-ons into a flattened BMessage. Such add-ons could be used by a system panel within the app or a system preferences app outside of the app to provide a natural interface that could suggest possible values for variables, and maintain constraints between them. (for example, greying settings that are made irrelevant by a change to another setting) Additionally, changes made in an interface provided by a compliant add-on could easily be provided to the application instantly to allow live update. (possibly via a set of standard BMessages - maybe derived from the scripting support?)

XML files are a relative newcomer to this show. There's no system parser for them (yet). So using them here would make an xml parser a requirement. Aside from the parsing/generating issues, XML files share many benefits with BMessages. They can contain nested structure, have references to add-ons, and add-ons could be used similarly. Another possible benefit of XML files is the ability to edit them in text editors, although this subjects you to most of the issues of the straight variable=value variety of text files. Still, I would consider it to be a handy backup in many cases. Without support for an XML system parser, I would lean towards BMessages. With support for an XML system parser, flattened BMessages could become xml files which would render the discussion moot. :-) Otherwise the issue remains.

Empty attributed files could also be used as preferences. This would be similar to the PeopleFiles, but instead of a set of standard attributes, each file would have attributes specific to that applications preferences. In this case there's no deep structure possible (yet). Attributes could possibly be edited directly from the tracker. (same problems of impoverished information) There could also be attributes that refer to add-ons that could provide an interface. These files have the drawback that you can't move them to a non-attributed file system. They can't be directly transferred by ftp as it is now. They can't be backed up directly to a non-attributed CD file system either. There would also be a proliferation of attribute types, although I don't think this is particularly a problem. One could also organize one's configurations in a tracker window with relative ease. Although this option has some "neat"-ness to it, I think would consider BMessages or XML files first.

more issues...

Aside from the file format there are also decisions to be made about APIs for the preference panel that apps can open, and the system preferences app. In my mind the system preferences app should be a minimal container for the preference panel with hardly any other functionality beyond it. KISS. :-)