[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Formal complaint concerning the use of the name "System Settings"
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2011-07-25 4:02:17
Message-ID: CA+XidOEK+EOYMhwnjCZsrtV5W_MsbvsSOQYO9oBaF6rYFk1H0Q () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jul 25, 2011 at 12:37 PM, Friedrich W. H. Kossebau
<kossebau@kde.org> wrote:
> Dimanche, le 24 juillet 2011, à 23:07, Ben Cooksley a écrit:
>> 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.
>
> This is quite insulting, I do not think many share your broad accusations, I
> least I hope not many do.
>
> Sorry, Ben, but someone who names his program with that general term "System
> settings" and expects it to have this name in all of the shells/workspaces
> (Gnome Shell, Unity, XFCE, Enlightenment, $WINDOWMANAGER, even in Windows and
> OS X?), while it only basically controls settings of the KDE runtime
> env/platform, is at least also one who is insular and only cares for himself
> (or his workspace), no? Think about it. At least to me System =
> Shell/Workspace or OS/Computer even.

I didn't choose the name. It was chosen a long time ago, when KDE 4.0
was originally forged. I rewrote it to add features, and became
maintainer around KDE 4.2. I kept the original name to avoid changing
things, and therefore creating user criticism.

I have already been criticised for changing the layout of modules in
System Settings. I am fairly sure that changing it's name would bring
similar criticism.

>
> And with my user hat on I would think this "Linux" is utterly shitty if I have
> to use different setting programs for all the existing toolkits out there, to
> do the same settings again and again.
> I am only looking out to also see Tcl Settings, EFL Settings, Gnustep
> Settings. Perhaps also some Motif Settings, to be old-school. Perfect! Not.

I haven't written any of the modules. I just know what is actually the case.

>
> If Joe user uses Unity and wants to use that hex editor Okteta someone
> recommended to him, would/should he need to know about "KDE" and that Okteta
> is implemented based on another toolkit than most of the default programs?
> I say No, and guess most users don't care as well (unless "toolkit racists").
> And thus he should also not need to know he has to use that other "System
> Settings" then the general system settings.
>
>> In any case, we need a short term solution to this. Basically, we are
>> going to have to provide a different name under GNOME, because
>> otherwise  GNOME users will complain to distros, who will patch GNOME
>> to ignore System Settings (I refuse to acknowledge their app).
>
> Well, the two desktop file solution might work, no? Name it "KDE System
> Settings" or similar for non-Plasma envs in one file, and "System Settings"
> for Plasma envs in the original one. Make that other file a patch for 4.7.1.
> Or did I miss something?

I already said it would. However certain people have complained that
this violates the branding, as "KDE" is the community rather than the
product.

>
>> A long term solution
>
> ... is to continue all the work that has been done to share as many settings
> as possible, and to support running programs in not-the-native environments,
> ideally without the need for a separate settings program for the toolkit in
> use, using some sane defaults there if needed.
> A big thanks for everyone who has done before or/and keeps pushing on this,
> like Aurélien with the "kdeui/kernel: Use platform palette and fonts" commit
> only last friday.

Of course that is the proper solution. Assuming they comply as well,
so their apps follow our settings in a KDE Workspace.

>
> And otherwise I completely agree with Cornelius.
>
> Cheers
> Friedrich
> --
> Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org
>

[prev in list] [next in list] [prev in thread] [next in thread]