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

[Mark]

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