desktop-entry-spec: Add an optional Keywords key
peter at peter-b.co.uk
Fri Dec 2 09:49:59 PST 2011
Vincent Untz <vuntz at gnome.org> writes:
> Le vendredi 02 décembre 2011, à 13:53 +0100, Florian Müllner a écrit :
>> On vie, 2011-12-02 at 12:43 +0000, Simon McVittie wrote:
>> > On Fri, 02 Dec 2011 at 12:35:09 +0000, Peter Brett wrote:
>> > > I just checked -- the Trinity DE (forked from KDE3) is still using the
>> > > "Keywords" key (and not "X-KDE-Keywords"). For example:
>> > >
>> > > http://git.trinitydesktop.org/cgit/tdebase/tree/kcontrol/input/mouse.desktop
>> > >
>> > > So yes, this might be a showstopper...
>> > ... although mouse.desktop does seem to have keywords broadly
>> > compatible with the GNOME proposal (except that they're
>> > comma-separated).
>> Yes, that was my impression from looking at other examples as well. I
>> very much favor semi-colons as separator (as that's what we use in
>> Categories and MimeTypes), but I'd be fine with allowing both
> Yeah, we really want semi-colons as it's a list.
As I mentioned in my other e-mail, semicolons are more or less
mandatory. It seems to me like there are two options (and a couple of
1) Re-use the "Keywords" key anyway...
a) ...and persuade the TDE guys to change their implementation in
order to accept either semicolons or commas as field separators.
Since they must have a parser that can handle semicolons as field
separators already (in order to handle other 'string(s)'-type
fields in .desktop files), it shouldn't be a huge challenge for
b) ...and persuade the TDE guys to switch to using "X-KDE-Keywords"
c) ...and ignore the problem, since the TDE folks have had several
years to either switch to using "X-KDE-Keywords" or to update
their parser to handle semicolons. After all, what Florian is
proposing is actually more-or-less directly compatible with the
way they're using the field.
Note that re-using the field assumes that we're okay with
(potentially) breaking users who install newer apps on desktops
running TDE or KDE < 4.0. If we go for this option, some minimal
investigation into the possible impact should probably be done.
2) Use a different key (e.g. "Related", "ExtraKeywords", or "Tags").
This is less nice from a semantic point of view, but has the
advantage of not risking compatibility issues.
Peter Brett <peter at peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
More information about the xdg