desktop-entry-spec: Add an optional Keywords key

[Peter Brett]

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
>> options.
>
> 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
variations):

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
      them.

   b) ...and persuade the TDE guys to switch to using "X-KDE-Keywords"
      instead.

   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.

Regards,

                              Peter

-- 
Peter Brett <peter at peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre