Trash spec: wrapping up

[Alexander Larsson]

On Fri, 2004-10-29 at 21:40 +0200, David Faure wrote:
> 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?

This field would be empty if the file trashing was "normal"? (i.e. from
a file manager or file selection dialog). Then that sounds fine to me.
Perhaps is should be called TrashContext or something instead of
Application though, because theoretically this type of special-casing of
some forms of trashing might be used among a set of apps.

One could even have an extra field TrashContextInfo that is context-type
specific origin data if the "original filename" part of the trashinfo
file isn't enough for the app to restor the file to the right place in
the database. E.g. In your example it could contain the album the
trashed file was from (given that the file path doesn't contain that
info). This would be a free form utf8-only string that the app could
handle however it likes.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a time-tossed guitar-strumming romance novelist trapped in a world he 
never made. She's a foxy African-American museum curator prone to fits of 
savage, blood-crazed rage. They fight crime!