There are many different desktop environments on GNU/Linux, but each has its own conventions for how to get and set various "system-wide" settings like the default web browser or proxy settings. The xdg-utils package provides cross-environment access to concepts like opening files and installing menu entries, but it does not extend to these sorts of settings.
A new xdg-settings script that provides access to these settings. It will have a get/set interface for named settings that map to whatever desktop environment configuration parameters are necessary to implement that higher-level concept. (For instance, there is no single "default browser" setting in either KDE or GNOME.)
Here is a table of the planned settings: (green background = implemented)
|Setting||Comments||GNOME mapping||KDE mapping||XFCE mapping|
|default-web-browser||Desktop file name: e.g. google-chrome.desktop, firefox.desktop||gconf:/desktop/gnome/applications/browser/exec,
handler for MIME type text/html via xdg-mime
|kdeglobals:BrowserApplication, handler for MIME type text/html via xdg-mime||~/.config/xfce4/helpers.rc, ~/.local/share/xfce4/helpers/*.desktop|
|proxy-mode||One of: none, auto, config-url, manual|
|socks-host||KDE does not have a SOCKS host setting; it delegates to an external library which must be queried for this setting|
|socks-host-port||See SOCKS host setting|
|proxy-config-url||The URL of a proxy auto-configuration file|
|proxy-exceptions||A space-delimited list of hosts, networks, and URLs to be excepted from the default proxy settings|
|proxy-exception-mode||One of: exclude, only. In "only" mode the proxy is not used unless the resource is listed in the exceptions|
|proxy-auth-mode||One of: none, prompt, config|
|proxy-persist||One of: persist, close, unspecified|
Most of these settings need only read support - applications can just launch the appropriate desktop environment configuration tool to allow the user to change them. (Perhaps xdg-settings should help do that, though?) However, some settings should be adjustable directly, because users expect applications to be able to change them from within the application. The default-web-browser setting is an example of this type of setting.
Writable settings add additional complexity for several reasons. First of all, care must be taken not to break the user's configuration files in attempting to make a change. (xdg-mime already fails in this regard to some extent, as it does not correctly preserve the preference order of handlers for MIME types when changing them.)
Second, some of these higher-level concepts map to many underlying settings. In KDE, for instance, the "BrowserApplication" setting may be (and is by default) empty, in which case the MIME handler for text/html is used. Further, the handler for that MIME type cannot be changed if the candidate desktop file does not claim to support it, and KDE removes MIME types from applications' desktop files if the user ever removes them from the list of applications that might be used to open files of that MIME type.
So, correctly reconfiguring all the possible settings that might have been previously set can be difficult, especially as there is (currently) no single, portable, authoritative way for applications to query the values of these settings - so many different settings must be changed to effect the desired user-level outcome.
Please discuss xdg-settings on the Desktop_architects or Portland mailing lists!