PACTHES: Desktop Entry Spec 1.0 - Take 2

[Bastian, Waldo]

>Le mardi 22 août 2006, à 17:22, Bastian, Waldo a écrit :
>> Below I will propose patches for the remaining open issues. If you have
>> changes that aren't in the updated version already and that aren't
>> mentioned below, please speak up.
>>
>> Process safeguard: The review period for these patches ends at Wednesday
>> Aug
>> 30. Without substantial opposition/requests for change I will commit the
>> patches after the end of the review period.
>>
>> * actions.diff and fixexample.diff
>>
>> Since this isn't widely supported yet I suggest to remove Actions for
>> the 1.0 version and add it back for a 1.1 version. I propose to apply
>> actions-2.diff which removes Actions for 1.0.
>
>I believe it'd be better to properly define this now, than to remove it.
>Is there a reason to not define it now?

The specification has two audiences, developers that implement a Linux desktop and developers that target the Linux desktop. With the 1.0 version of this spec I would like to capture the existing state of the Linux desktop so that developers that target the Linux desktop can take everything that is in the spec and can reasonably expect it to work on the (majority of) systems that their users are using. The 1.1 version can then again include new features that developers of Linux desktops intent to support in the future. Based on the above vision for the 1.0 version of the spec I don't think that the Actions should be part of it. KDE supports Actions in a very specific way and Gnome doesn't support them at all at the moment. It would be very confusing for developers that target the Linux desktop to read in the 1.0 spec about Actions only to find out the hard way that it isn't supported yet.

>> * regexp.diff
>>
>> Since the only user of regexp was FilePattern, which is now deprecated,
>> I suggest to remove regexp as type altogether. I propose regexp-2.diff
>> which removes regexp as type.
>
>This is minor, but I'd still like to add a note about the kind of regexp
>the FilePattern key is using (POSIX 1003.2 extended regexps make sense,
>I guess). To make it even stricter, we could write:
>
>"The value is a list of strings that are POSIX 1003.2 extended regular
>expressions to match against..."

But what's the point? The FilePattern key is deprecated and AFAIK no one has been using it for years. Why define anything that isn't used?

>(list of regexps is not a valid type anymore with your patch ;-))

I know, because nothing in the spec is using it anymore.

>> * versionkey.diff
>>
>> The field is currently listed as numeric with a well defined meaning,
>> making it easy to compare whether one version is older than another. Not
>> that anyone is actually using the Version field at the moment. I propose
>> to change according to versionkey-2.diff
>
>Your patch doesn't change the type to string.

That's intentional. The current type is "numeric" which comes down to anything sscanf("%f") can handle. 

>I'm not sure how the "Note that the version field is not required to be
>present." will work: once we'll have done 1.0, 1.1, 1.2, 2.0 and 3.0,
>what should the implementation assume?

The spec so far assumed, but didn't state, that compliant desktop files would include Version=1.0. In reality hardly any implementation does. Making the version field mandatory for 1.0 would break a lot of existing implementations and desktop files for no good reason. The 1.1 version of the spec can chose to make the Version field a required field. That only seems to make sense if a 1.1 version implies some sort of different behavior. It will depend on what will be in this new spec whether that is worth it.

Personally I don't see real value in the Version field at this point. A newer version of the spec is most likely to define one or more new keys and it's easy enough to detect the presence of these keys. Having a version field that says "this file may use an additional key" adds little value above just checking for that additional key in the first place.

>Also, I prefer the patch I sent in [1] since it defines the format of
>the string.
>
>[1] http://lists.freedesktop.org/archives/xdg/2006-August/008456.html

The numeric type defines the format as well.

>> * icon-theme-spec.diff
>>
>> Still a bit undecided on this one, but I wil commit this one as-is if
>> there are no strong opinions to do otherwise.
>
>Looks good.
>
>> * FSDevice
>>
>> FSDvice is currently only used by KDE. I have moved it's description and
>> the associated keys to Appendix B. Proposed patch is in
>> fsdevice-kde.diff
>
>Good one too.
>
>Vincent
>
>--
>Les gens heureux ne sont pas pressés.