Formal complaint concerning the use of the name "System Settings"

[Ambroz Bizjak]

Hi Thomas,

I'm not saying that the issues you have exposed do not exist. They are
however minor in nature and do not invalidate my solution.

> You call that "technical" and "not social"?
My proposal is technical. I have only mentioned the social aspects
when you have risen social issues about it.

> You'll at best be able to resolve risen clashes.
Yes, exactly. That's what the original problem was. The original
problem was not "We have to prevent ALL name clashes"; rather, it was
"System Settings clashes with a Gnome application". So I think we
should stay on point here and not wander into some utopian land you
seem to be imagining.

> And in a quite workload causing way - systemsetting would eg. require
> an "KDE System Settings" entry for _every_ desktop but KDE ...
You are mistaken here. I am afraid you just got a glimpse of my idea
which was really a case pointing out an issue in some other inferior
idea. Actually only this would be required in the System Settings
case:

Name=KDE System Settings
Specific-KDE-Name=System Settings

and would result in the program being called "System Settings" in KDE,
and "KDE System Settings" in everything else, including DEs which do
not know anything about my proposed extension.

I suggest you look at the whole mail history. My original proposal is
here (but I reversed the names there accidentally, sorry about that):
http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2

Regards,
Ambroz

On Tue, Jul 26, 2011 at 10:31 PM, Thomas Lübking
<thomas.luebking at gmail.com> wrote:
> Am Tue, 26 Jul 2011 21:53:48 +0200
> schrieb Ambroz Bizjak <ambrop7 at gmail.com>:
>
>> Hi Thomas,
>>
>> I hope you are aware that my proposal is a technical solution and not
>> a social one.
> No, it's probably not - see end of mail.
>
>> If the problem is "two things from different DEs have the same name",
>> then a direct solution to the problem is "make the names different".
> No, the solution of ambiguity is disambiguation - not adding more
> strings which could easily end up as ambigious.
>
> Again: the .desktop files already contain various identifying
> attributes.
> a) name
> b) generic name
> c) executable
> d) description
> e) (icon, but we'll leave that out)
>
> Whether your representation prefers the generic or non generic name is
> matter of pers. pref. but you can detect a clash and resolve it by
> adding more info. LLOD is the binary executable (in doubt including
> path & parameters) since that /has/ to differ for different entries.
>
>> And I have proposed a mechanism for doing exactly that, and doing it
>> in a simple an intuitive way.
> By adding an extra key for every possible DE...
>
>> Moreover, the mechanism is really generic as it would apply to all
>> keys in a .desktop file, not only a Name, so you can't ever claim that
>> it's a hack.
> a) how does that make/resolve it being a hack?
> b) where did I imply it was?
>
>> > If an application has a different name under different DEs, that's
>> > not "abuse" but error by design (sorry, i don't mean to be
>> > offensive)
>> Just no. It's abuse by the application author.
> So having different names on different DEs is not the intention of your
> approach (then why do you?) but abuse by the application author (where
> you drop accidents by the author/the translators...)
>
>> except for the very few specific cases where disambiguation is
>> required.
> Ans this is what i'm discussing. I didn't think of
> developers/translators deliberately confusing users at all.
>
>> > > This doesn't solve the original problem.
>> > Yes it does. They will certainly not share the same binary name or
>> > we've a _real_ problem. (Or not, since there will be only one target
>> > for the application link anyway ;-)
>> I'm not too sure what solution you're arguing here for, but I believe
>> that if you looked at this specific case (in particular the .dekstop
>> files) with a little more detail you would realize you're talking
>> nonsense.
> So you imply that (in this particular case) the gnome application and
> the KDE application share the exact same binary executable path as
> well as each and every other identifying attribute?
>
> Well, as mentioned before there is then no problem at all, since the
> user will run the very same application regardless of which icon (of
> that only one should exist anyway) he clicks. (of course the new problem
> would be that installing gnome would wipe parts of KDE...)
>
> Otherwise i am not talking nonsense at all.
>
>> I'm pretty sure all the translators problems would be solved by
>> mailing all translators something like:
>> ...
>> My proposal does not provide a mechanism for detecting clashes, only
>> one for resolving them. I'm sure that with a little attention from
>> application developers and listening to users, relevant clashes will
>> quickly be detected (as was the System Settings case).
>
> You call that "technical" and "not social"?
> Your approach relies on perfect communication _before_ a clashing
> release. That sounds more like "unrealistic" than "generic". Sorry.
>
> You'll at best be able to resolve risen clashes.
> And in a quite workload causing way - systemsetting would eg. require
> an "KDE System Settings" entry for _every_ desktop but KDE (and the "no
> desktop variant", just like the gnome variant required "Gnome System
> Settings" for every desktop but GNOME to prevent clashes) what could
> the ppl. you want to put this load onto (not me ;-) call it
> actually inferior to Mark's solution - which can not detect and
> effectively avoid clashes for sure but at least scales much better.
>
> Thomas
>