Le 23/07/2011 12:33, Emmanuele Bassi a écrit :
> On 2011-07-23 at 11:27, Dodji Seketeli wrote:
>> Matthias Clasen <matthias.cla...@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

Reply via email to