Design of a simplified and more intuitive user interface for DRIconf ==================================================================== September 2005, with small modifications in January 2006 Felix Kuehling 1. The Problem The current user interface of DRIconf reflects the structure of the configuration files and exposes it directly to the user. This makes it very powerful but can lead to confusing results, especially for users who do not think like programmers. * Multiple device sections can apply to the same physical screen. The order of sections matters. * Multiple application sections (in the same or separate device sections) can apply to the same application. Again, the order matters. * Devices that are not currently available can be configured. * If users forget to set the executable name, settings meant for a specific application apply to all applications instead. These facts can make it hard to track, which settings will actually apply to a given application on a given screen. 2. Requirements A simplified user interface should * show and modify only the user configuration file (not the system-wide configuration file), * use settings in the system-wide configuration file as defaults for new configurations, * show and modify only existing screens on the current display and * make it clear which settings will eventually apply to a given application. 3. Implications 3.1 Invisible sections The user interface will only show screens on the current display. Thus not all sections in the configuration file(s) are visible to the user. Invisible sections should not be modified by DRIconf, but they must not have any effect on visible devices. Thus sections for visible devices will always be written to the end of the configuration file. 3.2 Structure of the configuration file Parts of the configuration files written by the simplified UI will have a simpler structure. Device sections always identify devices by screen number and driver name. Each device section starts with a default application that overrides all options in order to cancel the effects of invisible sections. Application sections for specific applications follow after the default section, overriding only those options that the user wants to customize. 3.3 System wide settings As a consequence of 3.2 system wide settings will be overridden. Changes by the system administrator will not have any immediate effect on the user.¹ However, system wide settings should be honored as default values by the user interface when creating new device configurations or when resetting options to their default value. [modification: January 26, 2006] The case of creating new device configurations can only occur at startup when device configurations for all detected screens are created or read from the configuration file. The user cannot create new device configurations. [end modification] ¹) With the exception of new options that did not exist the last time DRIconf wrote the user configuration file. 3.4 Generating a simplified configuration from a complex one Whenever the simplified user interface loads a configuration file, it needs to generate a simplified internal representation of that configuration file that matches the original configuration as closely as possible. It should regard all sections in the user and the system-wide configuration file that apply to existing screens and ignore all sections that don't apply. Sections that do not identify visible devices by both screen number and driver name or sections that contain unknown options are regarded when reading the configuration file but are written back unmodified and in the original order as well, since they may apply to other devices possibly on other computers that are not currently visible. Only sections in the user configuration file that identify currently visible devices by both screen number and driver name and contain only known options are replaced by simplified device sections as described in 3.2. [modification: January 2, 2006] Invalid or unknown options in the user configuration file in device sections that specify both the screen and the driver and that affect an existing device should be included in the simplified configuration. Otherwise such settings would be silently lost in the simplification process. [end modification] The net result of this simplification process is a configuration file that has the same effect as the original configuration file in combination with the system-wide configuration and contains exactly one device section for each visible device at the end of the configuration file. 4. Proposed user interface 4.1 Devices The user interface must allow the user to select visible devices. Screen numbers and driver names are known and do not need to be entered by the user. The user interface may use glxinfo in order to obtain more intelligible information about the devices, for example the vendor and renderer strings. 4.2 Default settings For each device it should present the user with a configuration panel similar to the right pane of the current user interface. This panel should be used to set the default configuration of the device. As opposed to the current user interface the check boxes at the left of each option are not needed, since the device section will override all options. 4.3 Application settings The user should be able to configure specific applications. The executable name is mandatory. The screen that represents application configuration should show only the options that the user wants to modify. The user can add new options from a structured menu or remove options from the application configuration. 4.4 Miscellanea The user interface should work like a configuration panel in GNOME. This means: * The configuration file is saved implicitly each time a setting is changed. * No more button bar. * Devices are represented as tabs in a notebook. [modification: January 2, 2006] Option sections are already represented as a notebook. Nested notebooks do not look very clean. Instead a list of devices may be more intuitive. If only one configurable device is installed (the most common case) no device selection would be needed at all. [end modification] * Application overrides are hidden in an expander. 5. Expert mode The current user interface should be retained as an optional Expert mode. Expert mode should be selectable on the command line and in the simplified user interface. The latter means that both user interfaces should operate on the same internal data representation. Expert mode is entered automatically if a non-writable user configuration file is found. 6. Shared program components Simplified and expert mode can and should share some program components. * XML parser and associated data structures * Driver panel including option widgets. The driver panel will need modifications in order to hide check buttons in simplified mode. Interactions with higher levels of the user interface must be revisited in order to fit it into the new user interface.