On Tue, Jul 26, 2011 at 11:48 AM, Ambroz Bizjak 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-" and > revert to "" if the former does not exist. > > Regards, > Ambroz > > On Tue, Jul 26, 2011 at 9:54 AM, Mark wrote: >> On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak 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 wrote: >>>> On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak 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