Introduction

The Control Center, or "System Settings", is the place where Gnome shows settings and preferences that generally have no other context (i.e. are not specific to an application). Gnome tries to show only options that are generally useful for end-user systems. However, the need exists for a way to present options for things that are not as common, like specialized hardware or a server's settings.

This page explores the rationale behind having a generic way to present settings and preferences. You can call it "pluggable control center" or "specialized control centers" or whatever you want.

Considerations for panels in the control center

Application settings

These are particular to an application. A word processor's options go in the word processor, not in the control center.

System settings

These are not particular to an application, but rather are shared by things across the system. Your printer can be used by multiple apps, hence the Printer Settings panel. Your display is a shared resource as well. Settings for the desktop environment's chrome (24-hour or 12-hour clock? desktop background?) go in the control center as panels, too, unless that chrome can be configured more directly elsewhere.

Direct customization preferred over a settings panel

Imagine if Gnome Shell had an option for "number of items in the shell's overview" stashed in a panel in the control center. It would be better to have a couple of simple "show more / show less" buttons in the shell's overview, as this would make customization more direct.

Extensions to the desktop and their settings

A third-party extension to the desktop should strive to have direct customization as described in the previous section, instead of having to add a panel to the control center. If this is not possible within a reasonable user interface, then it is fine to have a custom panel in the control center: the extension effectively becomes part of the desktop shell, so its settings should appear in the same place as the rest of the system's.

Exotic hardware

Let's define "exotic" to be "things that you wouldn't expect a normal computer user to have". Here are a few examples.

• A Braille reader lets you read stuff from many accessibility-enabled applications, and it may need some options - in that case, it is fine to have a panel in the control center, as this is hardware shared by many apps in the system.

• A 3D printer may need software to control it, but that is more of a special-purpose application (the print-3D-stuff app), not a general-purpose module that many applications use. Thus, configuration for a 3D printer would not go in the control center. In the future, if various 3D modelers acquire a standard protocol to talk to 3D printers, then a panel in the control center may make sense - but not yet.

• Smart Home hardware (light dimmers, security cameras, whole-house music systems) falls into the category of special-purpose hardware with special-purpose applications, thus it does not go into the control center. However, it can go into a specialized "Home Hardware Settings" application; see below for special-purpose control centers.

In short, hardware that is meant to be used from a single application shouldn't have a panel in the control center. Hardware that is a shared resource probably needs a panel in the control center. Hardware that just happens to be controlled from/by your computer, but which doesn't interact with software other than the one that controls it, doesn't go in the control center - but it may go into an application for grouping special-purpose hardware; see the section "Special-purpose control centers" below.

Distribution-specific settings

GNU/Linux distributions often have features that are not part of upstream Gnome. They should follow the considerations above, and only include custom panels in the "System Settings" control center if they meet the criteria around general-purpose, shared resources. For example:

• Ubuntu's "Backup" feature - this is a general-purpose tool and is not specific to certain hardware. It is fine to go in the control center.
• Online services like Ubuntu One - they should try their best to go into the standard "Online Accounts" panel. They should be analyzed to see if the Online Accounts panel needs pluggability on its own, or whether they need complete panels on their own.
• Distro-specific tools like openSUSE's Yast - currently openSUSE simply puts a "Yast" icon in the control center, which causes Yast itself to be launched. This is not ideal as there are two configuration tools instead of one, but it is the simplest way in which to plug the distro's historic tools into the Gnome environment.

Special-purpose control centers

Consider these examples:

• Someone with several pieces of "smart home hardware" (light dimmers, security cameras, music systems) will want a central place to control it. The generic control center's shell could be made to show only configuration panels specific to that kind of hardware. This "Smart home settings" application would simply use the control center's generic code to create a shell and panels, and then load the custom-written panels for each piece of hardware.
• Hardware for weather geeks - they could have a "Weather Station Settings" application with panels for temperature/humidity/pressure measurements, etc.
• A "Server configuration" application, only for system administrators, may also want to use the control center's machinery to show a shell around configuration panels. There may need to be things that share code across the configuration panels "for users" and "for sysadmins", for example, the system clock or printers, but that's up to each particular panel to implement.

All of these special-purpose configuration apps can benefit from the generic features in Gnome's control center - accessibility, categorization, a good Human Interface Guidelines. There may be some ideas we can borrow from http://technet.microsoft.com/en-us/library/bb742441.aspx, but of course we have to be careful not to overdo things.

Special considerations

NVidia

The nvidia-settings application is GPL, but it is used to control a proprietary driver. There are things which the "display" panel in the stock control-center ought to be able to handle, but cannot, because NVidia doesn't support all the RANDR features we need. However, nvidia-settings also handles things that are particular to the NVidia driver, such as GPU performance parameters, which are not really of concern to Gnome.

It would be best if NVidia supported RANDR fully so that Gnome could control it as any other graphics driver. Then, at most NVidia may want to ship a control-center panel to control the exotic settings in their driver, but not the generic RANDR ones. Having NVidia-specific code in the "displays" panel doesn't sound attractive.

(If the configuration program were not free software, it would still be convenient for users to have an "NVidia" icon in the control center which would launch a separate utility.)

Examples of good and bad usage

We need these for the documentation on guidelines.

TO-DO: find out how distros are extending the control center's panels, and explain the rationale for why each is a good or bad addition.

openSUSE

openSUSE patches the control center to have an icon for YaST, Suse's tool for configuring system services and hardware. Some things are made superfluous by the control center's default panels (e.g. printer configuration), but some others are only in YaST, like firewall controls or users/groups. The rationale for putting this in the control center is "where would people look for system configuration stuff?".

Ubuntu

Ubuntu patches the control center to allow external panels. It has panels for “Privacy” (activity-log-manager's preferences for the Unity Dash and other programs, plus settings for submitting error reports), “Backup” (deja-dup), and “Time & Date” (settings for the menu bar clock, and a different design for changing the time and date).

“Additional Drivers” (settings for choosing binary drivers) is not a proper panel yet, and neither is Ubuntu One.

API

CcPanel - basically "here is a CcShell and an argv; give me back a widget to embed in the shell". (Why do panels need an argv?)

CcShell - Give me the shell's toplevel widget for when GTK+ needs it for things like the parent window of a dialog. Switch the shell to showing another panel (e.g. let the a11y panel switch to the keyboard panel). Have this other widget and embed it in the shell's header - is that for the "Unlock" button on e.g. the Printers panel?

CcShell is the parent class for GnomeControlCenter, which is the actual visible shell. None of the panels use the gnome_control_center_*() functions, just the cc_shell_*() ones. I don't know the purpose of this; it's probably so that others can implement their own shells and still reuse the machinery for individual panels. I'm ambivalent to this possibilty - the default shell seems generally good, but I can imagine special environments needing a different shell (small screens? who knows).