Am Tue, 26 Jul 2011 21:53:48 +0200
schrieb Ambroz Bizjak <ambrop7@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