GNOME and KDE are two of the most popular desktop environments for Linux. However, the relationship between the two groups have never been very cordial. They have had problems in the past and now, another problem has come up between the two of them.
KDE SC has been using the name “System Settings” to refer to its application used to configure the system – such as time, font, theme etc. Now, a conflict has arisen because GNOME, too. has started using the same name – System Settings – for its application which was earlier known as the GNOME Control Center.
System Settings - The GNOME one or the KDE one?
Users who use only KDE SC or GNOME will not notice any problem because of the conflict in the name. However, those who use both KDE SC and GNOME will notice the problem – and there are quite a lot of users who uses both of them.
A bug report has already been filed in Launchpad regarding this issue.
With today's rename of gnome-control-center to "System Settings" (LP:#733234), Unity users who install Kubuntu will have a difficult time opening the Settings app from the Unity Dash as there will be two applications using the same icon and with the same System Settings name. See the attached screenshot. It is the second (out of 3 actually) icon that is the "real" gnome-control-center.
The issue is not Ubuntu specific, but rather an issue with GNOME. So, Ben Cooksley, who maintains the KDE System Settings, sent a message informing the GNOME developers of the problem.
As you may or may not be aware, the name "System Settings" for an application is currently in use by KDE. A recent renaming by your GNOME control center developers to this name creates a naming conflict. This naming conflict will cause severe problems for users as a result. It will also cause problems for those members of the KDE Community supporting the usage of KDE applications on GNOME, as it will not be possible to adjust the settings used by KDE applications.
This will be because they will both appear, leading to GNOME packagers stupidly patching the system to not show the KDE System Settings under GNOME.
Many people have suggested renaming both the applications to resolve the conflict. But Cooksley rejects that, because KDE has had the name before GNOME and he believes they have the right to the name.
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, which will cause numerous problems for users on both sides. System Settings cannot just be shown on KDE, as the application is used to configure multiple settings shared between KDE applications such as Localisation (language, region, currency, calendar), Style, Colours, Fonts among others.
As KDE System Settings maintainer, I request that you immediately rename it once again to another name which is not in conflict.
Suggestions to solve the conflict
Jeremy Bicha suggested that GNOME change the name to “System Preferences” to resolve the issue.
I'd like to suggest that the GNOME developers consider changing the public name of their app to "System Preferences." This matches the Mac OS X design and arguably GNOME follows some parts of OS X design. Furthermore, it is more in line with Gnome 2's System>Preferences and System>Administration.
However, Matthias Clasen, a GNOME developer, called it an “absurd proposal” and rejected Cooksley’s claim to the ownership of the name “System Settings”.
That is an absurd proposal. What next, rename gnome-terminal to 'Commandline Window' because Xfce also ships a 'Terminal' ?! Generic names don't come with exclusive ownership...
However, one suggestion that have found the support of Cooksley is that from Shaun McCance. McCance suggested that having a shared groundword to make the settings interoperable between both GNOME and KDE. This is certainly a very good suggestion but it will take time to implement. As an immediate solution, McCance has suggested using two different .desktop files to make sure that only the relevant “System Settings” shows up in the relevant desktop environment.
We should work on shared groundwork so that our settings are interoperable. 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.
There's a very easy way to use a different application name under different desktops. Just install two .desktop files.
Cooksley has found McCance’s proposal acceptable. He said that KDE’s System Settings will be called “System Settings” under KDE but will be referred to as “KDE System Settings” under other desktop environment. With KDE SC 4.7 about to be released, it is too late to make the change. So, we might see the change in KDE SC 4.8.
KDE System Settings will continue to be called System Settings under KDE, but will be called "KDE System Settings" under all other environments.
If any GNOME components exist which do similar using of global names, particularly in the space of preferences, it would be much appreciated if you take similar steps.
GNOME does not like the solution - not interested any immediate fix either
Interestingly enough, GNOME seems to be against this as well. It is funny that GNOME started this whole mess by giving one of their applications the same name as an already existing KDE application – but they are still refusing to do anything about it even though KDE has found an acceptable proposal.
This is what Emmanuele Bassi, the Director at GNOME Foundation, wrote in reply to the proposal:
this is a non-solution, and an abdication of responsibility.
the real solution is to make it unnecessary (or even conflicting) to install the KDE system settings shell under a Gnome environment, and the Gnome system settings under a KDE environment; these are configuring the system settings, and you can hardly have two systems running at the same time on the same machine.
there is no "here and now" â€” that would be a hack. I hardly think we have to solve this *quickly*, so we should solve it correctly.
I get it that a unified settings management which works across different desktop environments is needed and that two .desktop files for one application is a hack at best. However, to implement the unified settings management will not be an easy and quick task. I find it unbelievable that GNOME is still stuck on this ideal system management and do not think that the problem which is affecting users right now needs to be solved.
According to Emmanuele Bassi, the short term fix would be to show the KDE System Settings correctly in KDE but not show it in other desktop environments.
the short-term fix is to make the KDE system settings OnlyShowIn=KDE, so that users running KDE will not have any issue, and every other desktop will correctly not show the KDE system settings shell.
This is the real issue right now. While KDE is open to the idea of having a unified Settings Manager which will work on both DEs, they believe that a short term fix is needed right now. Meanwhile, GNOME refuses to co-operate and are stuck in their lofty ideals of the the shared settings and do not want to make any changes to fix the current issue. They seem to be of the opinion that it is a KDE problem and that KDE should not show their System Settings under other desktop environments (remember that Cooksley offered to rename it to “KDE System Settings” under other DEs).
"they (GNOME) aren't interested in co-operating at all"
Because of the non-cooperation of GNOME on fixing the immediate issue, it seems like we will not see the unified shared settings between GNOME and KDE will not be possible as well. This is what Ben Cooksley wrote:
Dropping GNOME out of this, as it seems quite clear they aren't interested in co-operating at all. Which is fairly typical for them, they're insular and only care for themselves.
A long term solution, sharing settings isn't even counted, as they are bound to screw us over yet again in some way. They are not to be trusted.
There is bound to be more discussion at the Free Desktop Summit which will be held in Berlin from 6th to 12th August.
I believe that GNOME and KDE needs to work on the shared settings management – but for the time being GNOME should stop being so stubborn and work to provide an immediate fix to the problem.