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. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg