Trash specification, version 0.1

[David Faure]

On Friday 03 September 2004 09:44, Alexander Larsson wrote:
> On Thu, 2004-09-02 at 17:56 +0200, David Faure wrote:
> > On Thursday 02 September 2004 16:57, you wrote:
> > > On Thu, 2004-09-02 at 14:51 +0200, David Faure wrote:
> > > > On Thursday 02 September 2004 12:56, Alexander Larsson wrote:
> > > > > On Thu, 2004-09-02 at 10:44 +0200, David Faure wrote:
> > > > 
> > > > That'd work too. I was suggesting [Desktop Entry] + Type=something
> > > > because that's more consistent with what we (kde) do with
> > > > Type=MimeType, Type=Service, Type=ServiceType etc., but those
> > > > are parsed more or less together, whether trash info files are in a well-specified
> > > > directory (we know what type they are before even opening them).
> > > 
> > > Well, adding a Type to [Desktop Entry] in a spec would require changing
> > > the actual desktop file spec. (And it would confuse gnome apps that
> > > detect desktop files by sniffing and have no clue what type=TrashInfo
> > > means.)
> > 
> > Ah. Given the number of files in KDE that use [Desktop Entry]
> > and custom "Type" values (like the ones I cited above, and maybe more),
> > I think the gnome sniffing code should check for Type=Application anyway.
> 
> 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.

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

> Well, a specific mimetype isn't needed really. Its just that we can't
> use one that has a predefined semantics when we don't fullfil them.

The problem here is that the desktop entry standard only talks about Application
desktop files, since that's the only type of desktop files that kde and gnome share
currently, but it's really only one part of the picture - kde has had .desktop files
for other things since kde 1. They're just not specified in that spec since they're
kde-specific... But I really don't see a problem with using another Type for trashed
files.

> > If we don't care (for such a border case, arguably), then it doesn't matter what
> > we decide upon (as the group name etc.)
> > 
> > Hmm, in fact an intermediary solution is to append .desktop to info files, 
> > to end up with a constant mimetype (application/x-desktop), and use
> > whichever group in it, [Trash Entry] for instance. In the rare case where the
> > user opens the info/ dir, the files will at least not appear to be the original
> > ones, unlike those in the trash/ dir, so the user will know which files to
> > copy over, for emergency file restoration :)
> 
> 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 :)
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).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).