Trash specification, version 0.1

[Alexander Larsson]

On Fri, 2004-09-03 at 11:40 +0200, David Faure wrote:
> On Friday 03 September 2004 09:44, Alexander Larsson wrote:
> > Well. The mime sniffing code would have to read the whole file to look
> > for Type=something, which could be very slow. To only match the Types
> > listed in the spec as application/x-desktop would complicate the mime
> > database a lot.
> 
> OK. I was wrong about the mimetype-sniffing: this one can end up with
> application/x-desktop, this is exactly why we have a single mimetype
> for any Type of desktop file. It's the code that does stuff with the desktop
> files (launching, renaming etc.) which should check the Type.

I of course cannot affect how you use desktop files in KDE. I just think
it feels wrong to specify in a freedeskop standard that you're supposed
to use desktop files in a way that is not shown in the freedesktop
standard for desktop files.

People will read the freedesktop standard for desktop files, and then
they'll implement stuff based on that. Who knows what sort of problem
will show up in their implementations if new Type fields show up. Of
course, ideally a perfect app should check the Type field, and be coded
in a way that nicely handles bad input (after all, the user could have
put random binary data in the desktop file). However, in reality
software is fragile, and has bugs.

Its not like changing the toplevel group name changes anything for a
desktop file parser, so its very easy to make it a different type and
never have to worry about any mixups. I don't quite get the advantage of
pretending its a desktop file and having to have extra code to check
that the Type field exists and has a specific value.

> > Nautilus has special casing in a lot of places for desktop files. Like
> > how it presents their name, and how they are renamed (by changing the
> > name inside the desktop file). This type of trash "desktop file"
> > wouldn't even have a name. It could cause all sorts of strange things.
> 
> KDE mimetype .desktop files don't have a Name either! This is why I'm saying
> that the code that handles the Name field in .desktop files should only do that
> for Type=Application desktop files. Or for all, as long as you also handle the 
> case where Name is empty.

Yes. That is why when viewing /usr/share/mimelnk/image in Nautilus you
get a bunch of icons all called "No name". I know this isn't a huge
problem for kde, and its not likely to be a huge problem for gnome users
either. However, I don't see the advantage of allowing this problem to
show up at all.

> > That strikes me as even worse. Sniffing and extension matching will give
> > two different mimetypes, which causeses all sorts of problem.
> 
> Hmm, this is not what I meant.  In this last paragraph I was talking about
> using application/x-desktop as the mimetype, none other.
> You mean that the group being non-standard would make the mimetype be
> wrongly determined? Ah I forgot that you don't blindly trust the extension 
> of the filename like we do :)

This is what cross-desktop compatibility is all about. You can't expect
systems to behave like you're used to. All you can expect is whats in
the specs.

> OK so [Desktop Entry] would be simpler. I really think another Type shouldn't
> create problems, because if it does, then there are already problems (with
> KDE's non-Application .desktop files).

Yes. There is already problems. No, we don't have to make them worse.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an obese sweet-toothed gentleman spy with a winning smile and a way with 
the ladies. She's a hard-bitten snooty wrestler trying to make a difference in 
a man's world. They fight crime!