Re: Moving towards version 1.0 of desktop entry spec
Commited as 0.9.5 See http://www.freedesktop.org/wiki/Standards_2fdesktop_2dentry_2dspec On Monday 22 May 2006 22:57, Bastian, Waldo wrote: Looks ok, unless objections are raised I will commit these changes by the end of this week. Some additional comments: Re: encoding.diff In the chunk at line 148, I would mention that use of ENCODING is deprecated. Re: multiple-groups What about stating that multiple groups with the same name are not allowed? Otherwise we will need to make sure that different implementations actually handle this in the same way, which I fear they may not at the moment. Re: SortOrder I think it can be deprecated. It's currently underspecified and the menu-spec defines another mechanism for defining the order of menu-items. Re: FilePattern I am not aware of it being used in any way. Re: Other stuff 1) The section Priority of MIME types and desktop files doesn't seem to belong in the desktop entry spec. 2) Escaping of the exec parameters refers to mailcap and RFC1524. I don't think that is very helpful and/or accurate. Maybe we can come up with a simple command [args]* style syntax of things that are supported. 3) Non-absolute Icon= entries are labeled implementation-dependent. In an ideal world we would be able to refer to the icon theme spec here. Waldo Bastian Linux Client Architect - Client Linux Foundation Technology Channel Platform Solutions Group Intel Corporation - http://www.intel.com/go/linux OSDL DTL Tech Board Chairman -Original Message- From: [EMAIL PROTECTED] [mailto:xdg- [EMAIL PROTECTED] On Behalf Of Vincent Untz Sent: Saturday, May 20, 2006 2:45 AM To: xdg@lists.freedesktop.org Subject: Re: Moving towards version 1.0 of desktop entry spec Le samedi 22 avril 2006 à 10:04 +0200, Vincent Untz a écrit : Hi, Here's a small patch fixing really minor stuff in the desktop entry spec: I did some more work this morning. Here's a bunch of patches to apply in the following order: cleanup.diff cleanup2.diff encoding.diff swallow.diff reorganize.diff group.diff keys.diff cleanup.diff: the patch I sent a few weeks ago cleanup2.diff: some more cleanup, mainly adding some literal tags encoding.diff: move all of the legacy-mixed encoding stuff to the appendix swallow.diff: deprecate the Swallow* keys reorganize.diff: move lots of text around. It makes the spec easier to understand, IMHO. group.diff: improve definition of group headers keys.diff: reorder the list of standard keys so they are sorted by type I believe this should be okay for everyone, but make sure to verify :-) I don't have a fd.o cvs account, so I won't be able to commit them. But I can ask for one if necessary. Here's a list of things that I intend to work on: + move all the FSDevice-related keys to appendix B (Currently reserved for use within KDE). I won't make the change if some other project is using those keys or if people disagree. + define the type of regexp that is accepted. Any feedback on what it should be? + tell what should happen when multiple group headers have the same name. We could either merge them, only use the first, only use the last, etc. I'd say we should only use the last one. + change the type of the version key to string and specify its format (MAJOR.MINOR.MICRO where MAJOR, MINOR and MICRO are positive integers). 0.9.4 is not a numeric value ;-) + I don't think the SortOrder key is useful with the menu spec. Should it be deprecated? + is the FilePattern key used? Is there any other issue in this spec that we should solve? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg -- Linux Client Architect - Channel Platform Solutions Group - Intel Corporation pgpJOZMZTvmHg.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Moving towards version 1.0 of desktop entry spec
Looks ok, unless objections are raised I will commit these changes by the end of this week. Some additional comments: Re: encoding.diff In the chunk at line 148, I would mention that use of ENCODING is deprecated. Re: multiple-groups What about stating that multiple groups with the same name are not allowed? Otherwise we will need to make sure that different implementations actually handle this in the same way, which I fear they may not at the moment. Re: SortOrder I think it can be deprecated. It's currently underspecified and the menu-spec defines another mechanism for defining the order of menu-items. Re: FilePattern I am not aware of it being used in any way. Re: Other stuff 1) The section Priority of MIME types and desktop files doesn't seem to belong in the desktop entry spec. 2) Escaping of the exec parameters refers to mailcap and RFC1524. I don't think that is very helpful and/or accurate. Maybe we can come up with a simple command [args]* style syntax of things that are supported. 3) Non-absolute Icon= entries are labeled implementation-dependent. In an ideal world we would be able to refer to the icon theme spec here. Waldo Bastian Linux Client Architect - Client Linux Foundation Technology Channel Platform Solutions Group Intel Corporation - http://www.intel.com/go/linux OSDL DTL Tech Board Chairman -Original Message- From: [EMAIL PROTECTED] [mailto:xdg- [EMAIL PROTECTED] On Behalf Of Vincent Untz Sent: Saturday, May 20, 2006 2:45 AM To: xdg@lists.freedesktop.org Subject: Re: Moving towards version 1.0 of desktop entry spec Le samedi 22 avril 2006 à 10:04 +0200, Vincent Untz a écrit : Hi, Here's a small patch fixing really minor stuff in the desktop entry spec: I did some more work this morning. Here's a bunch of patches to apply in the following order: cleanup.diff cleanup2.diff encoding.diff swallow.diff reorganize.diff group.diff keys.diff cleanup.diff: the patch I sent a few weeks ago cleanup2.diff: some more cleanup, mainly adding some literal tags encoding.diff: move all of the legacy-mixed encoding stuff to the appendix swallow.diff: deprecate the Swallow* keys reorganize.diff: move lots of text around. It makes the spec easier to understand, IMHO. group.diff: improve definition of group headers keys.diff: reorder the list of standard keys so they are sorted by type I believe this should be okay for everyone, but make sure to verify :-) I don't have a fd.o cvs account, so I won't be able to commit them. But I can ask for one if necessary. Here's a list of things that I intend to work on: + move all the FSDevice-related keys to appendix B (Currently reserved for use within KDE). I won't make the change if some other project is using those keys or if people disagree. + define the type of regexp that is accepted. Any feedback on what it should be? + tell what should happen when multiple group headers have the same name. We could either merge them, only use the first, only use the last, etc. I'd say we should only use the last one. + change the type of the version key to string and specify its format (MAJOR.MINOR.MICRO where MAJOR, MINOR and MICRO are positive integers). 0.9.4 is not a numeric value ;-) + I don't think the SortOrder key is useful with the menu spec. Should it be deprecated? + is the FilePattern key used? Is there any other issue in this spec that we should solve? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Moving towards version 1.0 of desktop entry spec
Le dimanche 23 avril 2006 à 16:39 -0700, Bastian, Waldo a écrit : + is the FSDevice type used by a project? We don't use it in GNOME, and I'd like to deprecate it if possible. It's in use in KDE 3. + I wonder about the Actions key. It does make sense to me, but we don't support it in GNOME and we only had one (old) bug report about it. Do other projects use it? Used in KDE 3, though mostly in service menus and screensavers. I found only one case being used in the menus. For the things that are used in one imlementation but that aren't widely supported it's probably a good approach to keep them in the spec but mention that they are an optional part of the spec for know and specify what implementations that don't support the functionality should do with it. It depends on how you'd do it :-) If the thing is a feature that sounds useful to other projects which didn't implement it, then I believe we should leave it as it is, and mark it as optional. But we can also use a Currently reserved for use within XXX appendix (like what we have for KDE right now). Note that I can see how the Actions key can be useful, so I'd be inclined to implement it in GNOME. I'm less sure for the FSDevice type, for example. I expect that will come down to a slight more verbose version of Just ignore it. To be honest, I'm not fond of the just ignore it possibility in a spec (except maybe in an appendix). It just makes you doubt of what should be implemented (if you're an implementor) or what feature of the spec you can use (if you're a developer). Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
