PACTHES: Desktop Entry Spec 1.0 - Take 2

[Bastian, Waldo]

I have commited icon-theme-spec.diff and fsdevice-kde.diff. Would be nice if there was some more feedback on the other points mentioned so that we can move that forward as well, one way or the other.

Cheers,
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.