Trash spec: wrapping up

[David Faure]

On Friday 29 October 2004 20:48, Matthias Clasen wrote:
> On Fri, 2004-10-29 at 14:37, David Faure wrote:
> > On Tuesday 26 October 2004 11:46, Alexander Larsson wrote:
> > > I still think that we must store the actual byte-string in the file, as
> > > opposed to converting it to some other encoding. However, it would be
> > > nice if the text file was still valid UTF8, and it needs to be able to
> > > contain all sorts of files, including those with newlines in the name.
> > > 
> > > Thus, i propose that we store the byte string in escaped form in the
> > > trash info file. The normal desktop file escaping method doesn't allow
> > > encoding of any byte value, so we can't use that. To avoid multiple
> > > escape/unescape problems when using existing desktop parsers we
> > > shouldn't extend that method. Instead i propose that we use url-style
> > > escaping. 
> > 
> > So we would have (for a french-like e+accent)
> > Path=%E8.txt
> > if the filesystem uses latin1, and
> > Path=%C3%A9.txt
> > if the filesystem uses utf8?
> > 
> > OK, this makes the whole .trashinfo file pure ASCII, even.
> > I'm not sure how that helps, though. After un-escaping you're back to the
> > same situation (e.g. a filename that is potentially invalid in the current locale)
> > 
> > And the name of the .trashinfo file itself would still contain the special char
> > (one or two of them, depending on the encoding being used)...
> 
> What you win is that (the content, maybe not the name of) the .trashinfo
> file itself is valid UTF-8, thus you can use existing parsers (eg for
> the desktop entry spec) which expect to parse valid UTF-8

OK then.

Another thing: I got the request from other KDE developers to add the name
of the application which trashed a file, into the .trashinfo file.
That way it's possible for an image-viewer to trash files, 
and to later on display the list of files that it trashed itself (as opposed to 
showing all trashed images, which didn't come from those albums, or all 
trashed files). This makes especially sense when the image application
has its own albums for organizing images, so it really only wants to undelete
files deleted from one of its albums, not images deleted from other parts
of the filesystem with a filemanager.

So I'll be adding an Application= field to the .trashinfo files. Should we
add this to the spec?

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