Desktop name collisions

The GNOME and KDE development communities ran into a potentially confusing name collision recently when it was discovered that both were using "System Settings" to label the menu entry for their respective environmental configuration tools. A plan for handling the redundant names was eventually hashed out, though it shed light on a variety of other issues about system configuration on modern Linux desktops.

The debate started when Ben Cooksley, maintainer of KDE System Settings, wrote to both the GNOME desktop-devel list and KDE kde-core-devel lists with what he termed a "formal complaint" about the name change in GNOME 3's unified configuration tool, from "Control Center" to "System Settings." Cooksley argued that users would be confused by the presence of both GNOME's System Settings tool and KDE's, and that GNOME "packagers" (meaning downstream distributions) would disable the KDE tool, thus leaving mixed-environment users without a way to configure important KDE application settings. Because KDE was using the term before GNOME, he ended the complaint requesting that GNOME "immediately rename it once again to another name which is not in conflict."

Outside of the core issue, Cooksley's initial few messages were openly combative in tone, accusing the GNOME project of deliberately choosing the same name; remarks like "as KDE occupied this name first, it is ours as a result, and I will NOT be relinquishing it to satisfy your personal (selfish) desires" threatened to derail any serious discourse. A few other posters in the two threads also reacted with acrimony, but list moderators Olav Vitters (GNOME) and Ingo Klöcker (KDE) were quick to step in and warn participants to keep the discussion civil. For the most part, the discussion did calm down, and focused on the technical challenge of permitting two system configuration tools to co-exist — a challenge without an easy solution.

Configuration Junction

The root of the potential confusion is that both KDE and GNOME handle desktop-wide preferences for a range of settings that their constituent applications need: localization, mouse settings, keyboard shortcuts, preferred file-handling applications, even widget and sound themes. Many of the settings are defined in Freedesktop.org specifications, but some are unique to just one desktop environment or another.

In both cases, the name given to the settings-configuration application is generic rather than customized and unique, as it is for most desktop environment utilities. Few on either list gave much credence to the notion that KDE had "dibs" on the generic usage of the name System Settings. Generic names, after all, are by their very nature going to attract name collisions. Shaun McCance observed that "you just can't expect to own generic names across desktops."

Jeremy Bicha even pointed out that a previous name collision between the two projects happened in the other direction, with KDE duplicating the name System Monitor, which GNOME had already been using for years:

When on an entirely-KDE or entirely-GNOME system, the name of the other environment's configuration tool theoretically should not matter, but when users install applications from the other environment, the other tool could get pulled in as a dependency, and users are faced with two menu entries named "System Settings." As several people on the thread pointed out, simply renaming one tool or the other to "System Preferences" does not solve the problem, as in either case it is unclear which tool is associated with which environment. Niklas Hambüchen added that although "preferences" and "settings" may be two different words in the English translations of the strings, in many others languages the two tools might still end up using the same word.

GNOME has an OnlyShowIn: GConf key that it uses to make its System Settings appear only in GNOME Shell and Unity, so users running KDE (but using some GNOME applications) do not see the name-colliding menu entries. But as Cooksley and Bicha pointed out, the same solution does not work for KDE, because a substantial number of KDE applications expect the KDE System Settings tool to be available in the menu, even when running under GNOME (or another environment).

McCance suggested that each configuration tool include two .desktop files (which are used by both environments to build the system menus): one for the "native" environment which would use the generic "System Settings" name, and one for the non-native environment, which would prepend "GNOME" or "KDE" to the name, for clarity. Although that approach is possible under the Freedesktop.org .desktop specification using the OnlyShowIn= and NotShowIn= keys, Cooksley said it was already too late to make the change in KDE's .desktop files because the project had already frozen for its 4.7.0 release in August.

Several others felt that supplying two .desktop files for a single application was inelegant, and that the .desktop specification needed patching to specifically support applications that provide different names in different environments. User markg85's recommendation involves adding entries for NativeDE=, and a NameNonNative= key that would be used to provide an alternate name.

On the kde-core-devel list, Ambroz Bizjak offered up a slightly different proposal, in which each application would include a Name= key (as they do currently), but add a Specific-KDE-Name= key for use in KDE, and a Specific-GNOME-Name= key for GNOME, etc. The debate over the difference between those two proposals (and variations of each) is currently ongoing on kde-core-devel.

KDE applications and configuration

A tangent arose in the initial discussion over tool names asking why a KDE application would depend on the external KDE System Settings tool's presence when running under GNOME. Alex Neundorf said there were many configuration issues that could only be set through KDE System Settings, such as "widget style, colors, printing, file associations etc." Cooksley added Phonon, keyboard shortcuts, date/time and localization, and theme.

Giovanni Campagna insisted that those examples should actually be classified as bugs (either in KDE or in the particular application), because the majority of the settings in questions should be accessible to applications regardless of the desktop environment running, either through XSETTINGS, D-Bus, or other means. The KDE Wallet password-storage application mentioned by Cooksley, for example, should be used if the environment is KDE, but all KDE-based applications should follow the .org.freedesktop.Secrets setting, which will direct them to gnome-keyring if the environment is GNOME. Emmanuele Bassi said that most GTK+-based applications currently do adhere to the Freedesktop standards.

Aurélien Gâteau commented that he has been patching KDE applications to do better in this regard, so that "isolated" KDE applications will more closely follow the behavior of generic Qt applications, and pick up the configuration settings set by the environment. He said that there were "very few" applications that can only be configured through a KDE Control Module (KCM) (the type of component presented in KDE System Settings); all others should be completely configurable through their own Settings menus.

The effort to standardize KDE application behavior is obviously ongoing. Later in the thread the personal finance manager KMyMoney came up as another example of an application that relies on KCM components in KDE System Settings to configure its localization settings. Ryan Rix pointed out that KMyMoney could embed the localization KCM.

As for XSETTINGS support, Frédéric Crozat commented that he had written KDE support for the specification in 2007, but that the code had yet to be merged. Gâteau added that he was under the impression that the specification was still in the draft stage, and not ready for public consumption.

KWord developer Thomas Zander said that the whole situation should be treated as a "call to action":

The short-, medium-, and long-term

It is still not entirely clear what the KDE developers' plan is for 4.7.0. Cooksley concurred with McCance's proposal to use OnlyShowIn= and NotShowIn= keys as a "medium" term solution. When asked why he could not make the changes to KDE System Settings' .desktop files in Subversion and have a "short" term fix ready before August, though, he replied that as per the KDE Release Schedule, only build fixes are permitted after the freeze date.

In the medium term, it does appear that KDE will take the dual-.desktop approach, and that the discussion over additions to the .desktop specification is an attempt to find a "long" term solution. The longer that discussion continued, however, the more people began to comment that the truly long-term approach would be to obviate the need for every environment to provide its own set of system settings tools, particularly when the tools control the same underlying cross-desktop specifications. Two silos of settings are bad enough, but two tools controlling the same settings is a scenario with problems of its own.

For that problem, no one has yet drafted a proposal. But it is not only the KDE camp that recognizes the issue; in his proposal to the desktop-devel list, McCance argued that working on a shared groundwork was the best path forward, saying "if a user has to set his language in two different applications just because he happens to use applications written in two different toolkits, we have failed miserably." The good news is that the KDE and GNOME teams will both be in Berlin the second week of August for the Desktop Summit. Hopefully the long-term answer will inch a little closer to the present as a result.