Trash specification, version 0.1
alexl at redhat.com
Fri Sep 3 10:44:24 EEST 2004
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.
> But from a mimetype point of view, I see what you mean: either this is
> application/x-desktop (and we don't know what to do with it since it's not a real one)
> or we have to invent a new mimetype (not that we'd know what to do with it either,
> but at least people would get a constant icon for the info files if they ever open that
> directory in a filemanager, instead of getting extension-dependent icons and
> mimetypes, which would create trouble - e.g. info/foo.png isn't actually a PNG)
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.
> Basically, if we care about people opening info/ in a filemanager, then we need
> a mimetype like application/x-trashinfo _and_ we need to append .trashinfo
> (or whatever) to every file there.
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.
> 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.
Alexander Larsson Red Hat, Inc
alexl at redhat.com alla at lysator.liu.se
He's a fast talking small-town dwarf living undercover at Ringling Bros.
Circus. She's a wealthy communist traffic cop with the power to bend men's
minds. They fight crime!
More information about the xdg