Re: Formal complaint concerning the use of the name "System Settings" by GNOME
- From: Aurélien Gâteau <agateau kde org>
- To: kde-core-devel kde org
- Cc: gnomecc-list gnome org, desktop-devel-list gnome org
- Subject: Re: Formal complaint concerning the use of the name "System Settings" by GNOME
- Date: Sun, 24 Jul 2011 01:18:29 +0200
Le 23/07/2011 12:33, Emmanuele Bassi a écrit :
> On 2011-07-23 at 11:27, Dodji Seketeli wrote:
>> Matthias Clasen <matthias clasen gmail com> a écrit:
>>
>>> I don't think Shauns proposal addresses the issue, really.
>>
>> Why? Do you have an example that would show where Shaun's proposal
>> falls short?
>
> it falls short in showing:
>
> System Settings
> KDE System Settings
>
> under Gnome, and:
>
> System Settings
> Gnome System Settings
>
> under KDE.
>
> now, if you got a computer without having it installed yourself, and you
> read the applications list, do you know what "KDE" or "Gnome" are?
Most distributions split KDE packages so if you get a pre-installed
computer with Gnome and a few KDE applications installed, KDE System
Settings would not be installed.
You are only likely to get both System Settings pre-installed if your
computer was shipped with both KDE and Gnome desktops. In this
situation, I assume you would be provided with some explanation as to
what KDE and Gnome are.
> applications should not be configured through the *system* settings; and
> both system settings shell should configure the same services.
Agreed.
>
>>> If you want an app to be usable in different environments, then there
>>> are some good solutions:
>>> - make sure the app is self-contained and manages all of its settings itself
>>> - make your app smart enough to pick up the relevant settings from the
>>> different environments you want to support
>>>
>>> And there are bad solutions, including:
>>> - making the app drag along half of its original environment, via dependencies
Agreed as well, but very few applications actually depends on KDE system
settings. At least on my Ubuntu box, only knemo and kinfocenter do (if
apt-cache rdepends is to be trusted) and they are system-related utilities.
>>
>> You don't say why these would better address the issue "here and now" in
>> comparison with what Shaun is proposing.
>
> 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.
Releases are conflicting right *now*, so yes, I think there is a need to
solve it quickly, even if the first fix is a short-term one.
Aurélien
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]