Version: (using KDE KDE 3.5.2) Installed from: Gentoo Packages I ran desktop-file-validate¹ on the 1.5.1 desktop entries, the results (warnings stripped) follow. [1] http://freedesktop.org/wiki/Software_2fdesktop_2dfile_2dutils
Created attachment 16120 [details] desktop-entry-errors
Files with Type=ServiceType (or MimeType) are kde-specific and shouldn't be validated with desktop-file-validate. It's perfectly fine that they use PropertyDef:: for instance, since no other piece of code than KDE is going to read them. In fact only Type=Application files should be validated this way. Can you post an updated log?
> Files with Type=ServiceType (or MimeType) are kde-specific Im aware of it, but Boudewijn asked me to file a bug, in response to my email. Apart from it - and this is of course something for KDE 4 - I do think even KDE specific desktop entries should follow the f.d.o standard. >Can you post an updated log? Um, I don't feel tempted. Shouldn't a small script checking for this be part of your release QA tools?! ;p
On Tuesday 16 May 2006 20:36, Carsten Lohrke wrote: > > Files with Type=ServiceType (or MimeType) are kde-specific > > Im aware of it, but Boudewijn asked me to file a bug, in response to my > email. Apart from it - and this is of course something for KDE 4 - I do > think even KDE specific desktop entries should follow the f.d.o > standard. That sounds logical, but the spec just does not describe our extentions. For example; http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html lists key 'Type' to have a choice of 4 values; Application, Link, FSDevice and Directory. So, having an error message like: ./kexi/data/x-kexiproject-shortcut.desktop: error: required key "Name" not found, while the 'Type' in that file has a value of 'MimeType' means that the most important field is not checked in the tool. Further checks are based on wrong assumptions. > >Can you post an updated log? > > Um, I don't feel tempted. Shouldn't a small script checking for this be > part of your release QA tools?! ;p Well, you seem to have it installed already... If you can do a: (on one line) find koffice -name '*.desktop' -exec grep -l 'Type=Link\|Type=Application' "{}" ';' > filesToCheck and go from there, that would be great.
On Tuesday 16 May 2006 21:19, Thomas Zander wrote: > That sounds logical, but the spec just does not describe our extentions. > For example; > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html > lists key 'Type' to have a choice of 4 values; > Application, Link, FSDevice and Directory. Yes. Please understand this: the other desktop files are not installed into directories where other environments would look. So what does it matter? One shouldn't check all .desktop files in the source code, but rather all -installed- desktop files in the standard directories (applnk and applications), excluding the kde-specific directories (services, servicetypes and mimelnk) > So, having an error message like: > ./kexi/data/x-kexiproject-shortcut.desktop: error: required key "Name" not > found, while the 'Type' in that file has a value of 'MimeType' means > that the most important field is not checked in the tool. Further checks > are based on wrong assumptions. This is how Type=MimeType files work in kde3. The tool is wrong (but it doesn't matter since only kde uses such files).
> That sounds logical, but the spec just does not describe our extentions. Non-standardized (extended) .desktop files are illogical. From my point of view there are two ways to solve it for KDE 4: Either adhere to the standard or use another extension, so no one confuses the files with f.d.o desktop entries. You ask why? Let assume every Linux desktop / wm has it's own extended .desktop files - how should a distributor do (automated) quality checks, when telling these different .desktop entries apart is the very first problem!? > Please understand this: the other desktop files are not installed into directories where other environments would look. Once again: I am quite aware of it. KDE just isn't the center of the Linux world and adding directory excludes etc. for KDE, foo, bar, baz could become cumbersome at some point. Standardizing the extended functionality where it makes sense and otherwise respecting the standard is preferable. Please play nice. :) Maybe I can use this bug to place a related question: I had to deal with an app shipping a broken service .desktop entry, lately and the only way to fix it was to look at similar installed ones. I assume there's a spec/description for these "extended" .desktop entries, but I couldn't find it. Could you point me to it, please!? Exists a validator?
On Wednesday 17 May 2006 20:48, Carsten Lohrke wrote: > how should a distributor do (automated) quality checks, when telling these different .desktop entries apart is the very first problem!? By looking into the standard directories (share/applications and share/applnk) only. I'm not opposed to changing this in kde4, of course, I'm just pointing that this isn't that much of a problem as it is.
do you still have this bug?
Not a bug, as explained in #5 / #7.