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

[Ambroz Bizjak]

(Mark, sorry if you're getting this twice, I clicked the wrong Reply
button the first time...)

Hi Mark,

I understand your concern, but I don't consider it an issue.

There is a downside to your proposal compared to mine, which is that
it only allows a specific value to one (!) DE. For example, with mine,
you could have:

Name=Some Generic Name
Specific-KDE-Name=Name in KDE only
Specific-GNOME-Name=Name in GNOME only
Specific-XFCE-Name=Name in XFCE only

the result of which would be that there would be specific (possibly
different) names for KDE, Gnome and Xfce, and a default name for other
DEs. The same is not achievable with your suggestion.

I suppose it would be possible to achieve this without embedding any
value in the key itself, but it would become harder to read and to
implement. For example, the following:

Name=Some Generic Name
Specific-Name-Count=3
Specific-Name-Desktop0=KDE
Specific-Name-Value0=Name in KDE only
Specific-Name-Desktop1=GNOME
Specific-Name-Value1=Name in GNOME only
Specific-Name-Desktop2=XFCE
Specific-Name-Value2=Name in XFCE only

which I think is flawed compared to the above version. It's hard to
read and to modify, harder to implement, and introduces unnecessary
coupling between the fields.

What do you think?

Regards,
Ambroz

On Tue, Jul 26, 2011 at 1:19 PM, Mark <markg85 at gmail.com> wrote:
> On Tue, Jul 26, 2011 at 11:48 AM, Ambroz Bizjak <ambrop7 at gmail.com> wrote:
>> Hi Mark,
>>
>> I am strongly opposed to the particular solution you are implementing.
>> You are trying to extend the desktop file specification in a very
>> non-generic and non-intuitive way, and people will obviously oppose
>> that.
>>
>> The particular problems I see with your original proposed solution are:
>> - You are only extending the "Name" field. It will not be possible to
>> have a DE-specific GenericName field, for example.
>> - You are adding two new fields to the specification, when the same
>> effect could be achieved with just one new field (or class of fields)
>> - Anything that is not aware of the your extension (which probably
>> means it is not KDE) will be using the KDE-specific name rather than
>> the generic name, until that software was patched to understand the
>> extension.
>>
>> Please consider my second suggestion - it is a much more generic
>> solution, and it does not have any of the problems I listed above.
>>
>> http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2
>>
>> I'm sorry, I messed up the example there; it should say:
>>
>> Name=KDE System Settings
>> Specific-KDE-Name=System Settings
>>
>> To implement this solution I guess you'd have to modify
>> KConfigGroup::readEntry to first look for "Specific-KDE-<name>" and
>> revert to "<name>" if the former does not exist.
>>
>> Regards,
>> Ambroz
>>
>> On Tue, Jul 26, 2011 at 9:54 AM, Mark <markg85 at gmail.com> wrote:
>>> On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak <ambrop7 at gmail.com> wrote:
>>>> Hi Mark,
>>>>
>>>> The localization stuff you're concerned about is happening below the
>>>> desktop file layer (in KDE's case, kconfigdata.h), and should work
>>>> automatically, i.e. if you ask for some key it will automatically give
>>>> you a localized version if available.
>>>> Also, DE-specific desktop file keys would be a good thing to have in
>>>> general, so I hope people do not oppose the idea just because it's not
>>>> the ideal solution to this particular problem. Besides, it's (I think)
>>>> very easy to implement, so even if we don't manage to push it, it
>>>> wouldn't be that much time lost :) . I've done many enhancements to
>>>> open-source projects, and many of them weren't liked by the developers
>>>> - but I still think I did the right thing, and I'm not afraid of
>>>> contributing for the fear of being opposed.
>>>>
>>>> Regards,
>>>> Ambroz
>>>>
>>>> On Tue, Jul 26, 2011 at 12:19 AM, Mark <markg85 at gmail.com> wrote:
>>>>> On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak <ambrop7 at gmail.com> wrote:
>>>>>> Hi Mark,
>>>>>> I've done some small research on what components would have to be
>>>>>> updated for the desktop-specific-names solution. I think that would
>>>>>> be:
>>>>>>
>>>>>> - The Desktop Entry Specification,
>>>>>> http://standards.freedesktop.org/desktop-entry-spec/latest/
>>>>>> - KDE's KDesktopFile,
>>>>>> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp
>>>>>> - Xfce's libxfce4menu, in particular
>>>>>> http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c
>>>>>> - Gnome's libgnome-menu, in particular
>>>>>> http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c
>>>>>>
>>>>>> Regards,
>>>>>> Ambroz
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanx for the list. I already found the spec and kde file.
>>>>> One thing i can't find though is the part that makes multilanguage
>>>>> stuff for desktop files working.. Those 3 source files all just grab
>>>>> the Name value but where does it do the magic that happens when i set
>>>>> my language to dutch.. then it grabs Name[nl] but where does it do
>>>>> that? Asking that since the properties i proposed should have multi
>>>>> language suppert as well..
>>>>>
>>>>> And besides that.. I do want to implement it, but i'm getting the
>>>>> feeling there isn't that much support for it thus wasting my time if i
>>>>> implement it since it won't get accepted anyway. (which i rather
>>>>> avoid).
>>>>>
>>>>> It's just a feeling and i hope i'm wrong...
>>>>>
>>>>> Regards,
>>>>> Mark
>>>>>
>>>>
>>>
>>> You are completely right.
>>>
>>> However one small question.. In KDE you have a readName function that
>>> reads the Name value from the desktop file. But how should that behave
>>> if a desktop file has the following and is read from a KDE
>>> environment:
>>>
>>> NativeDE=Gnome
>>> NameNonNative=Gnome System Settings
>>>
>>> Would the readName property then return the NameNonNative value if
>>> it's read from a KDE environment..?
>>> That would seem the most easy solution but a bit dirty as well -- only
>>> seems nice if the spec would specifically say that the Name property
>>> is overwritten by NameNonNative if the NativeDE property is set and
>>> different from the currently used DE.
>>>
>>
>
> Hi,
>
> Oke, i understand, but with your solution you would get a DE spec
> change for every DE.. that should not be the case i think. For
> example, with your proposal you would get:
> Specific-KDE-Name=...
> Specific-GNOME-Name=...
> Specific-XFCE-Name=...
> Specific-LXDE-Name=...
>
> and every other DE out there.
>
> So.. a mixture between our proposals is probably the best idea like this:
> Name=KDE System Settings
> SpecificDesktopEnvironment=KDE
> DestopSpecificName=System Settings
>
> This would be adding just 2 new keys to the spec and with the
> flexibility that you want. And can work on all desktop environments
>
> How about that idea?
>
> Regards,
> Mark
>