[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:       Ambroz Bizjak <ambrop7 () gmail ! com>
Date:       2011-07-26 9:48:12
Message-ID: CAOA3yKJhXqDPdFyuHZhcNY4aM=UL9gFK_QzSLc06+kTMQ0fEUg () mail ! gmail ! com
[Download RAW message or body]

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@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak <ambrop7@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@gmail.com> wrote:
> > > On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak <ambrop7@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.
> 


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