Trash spec 0.4

[David Faure]

On Thursday 09 September 2004 15:12, Alexander Larsson wrote:
> Lets keep it. It should be ok. 
Great, thanks.

> So, you resolve the symlinks. That does make it work.
> Take this example for instance:
>  fs mounted on /mnt/md1
>  /opt/foo -> /mnt/md1/i386-foo
>  trashing /opt/foo/file.
> 
> The trashdir would be /mnt/md1/.Trash/$uid/.
> And the info file would contain "i386-foo/file".
> It does sort of leak the symlink abstraction into a user file. Although
> i guess that is right. If you untrash it on a machine where /opt/foo
> points to /mnt/md1/i686-foo you do want it back in i386-foo, not i686-foo.
> 
> The spec should perhaps mention something about fully resolving the
> symlink before generating the relative pathname.
Agreed.

> > I agree to what you say, but I don't really see a contradiction with what Mikhail
> > wrote (except for the utf8 fallback). OK the fallback doesn't make sense,
> > since we currently always know which encoding to use for filenames (even
> > though in kde we assume it's the same everywhere).
> > Well this is opening a whole can of worms currently since Qt/KDE doesn't do
> > this right for systems with multiple encodings, since we convert everything
> > to Unicode. No need to explain to me at length why this is wrong, I know it is,
> > bu that's how it is currently. So let's use the Encoding field like in the 
> > desktop entry spec, to define what's the encoding used in the trashinfo file,
> > otherwise we'll never be able to guess what to use.
> > Currently KDE always uses UTF-8 when generating .desktop files (and trashinfo files),
> > but at least with an explicit encoding we'll have less interoperability problems
> > (if the trashinfo file contains a kio8-r path, the encoding will say so, and everyone
> > will be able to read it correctly).
> > Basically this is just like .desktop files with an Exec line; let's not invent another solution.
> 
> So, what if I run in the utf8 locale, but have an old file with an
> iso-8859-1 encoded filename? 
This doesn't work already, in KDE, when talking about actual files on the filesystem,
since we assume "one file encoding used everywhere".
But in environments where it works - surely you have to know that it's latin1,
otherwise you can't display it correctly in the file manager, can you?

> Or I somehow got a file with a kio8-r 
> filename from some tarball i unpacked? Given just a filename on the
> filesystem to trash, how am I supposed to know what encoding to put in
> the Encoding field?
Same as the encoding you use to display that filename in the GUI...
If unknown, well, then there's no solution. OK there's the solution of keeping
the raw 8-bit representation for all file access and the only bug is the bad display
of the filename in the GUI - I understand that. That's just an option for me 
right now (design decision in Qt - everything is Unicode). This is the kind
of sentence after which I wish I wasn't using a trolltech.com email adress,
since I don't really work for TT; at least not on Qt :)

> And, even if I somehow magically knew the filename was in kio8-r, say it
> was "/opt/<kio8-r string>/file". If I save the encoding as kio8-r in the
> trashinfo file, then KDE will know how to read this file and convert the
> name to unicode. When "untrashing" it'll try to restore it to "/opt/<you
> locale string>/file", but "/opt/<your locale string>" doesn't exist, so
> it fails.
True.

OK, then there's no interoperability when using different encodings on
different filesystems, or in different environments - nothing new there.
Hmm, in fact that should be "no interoperability with systems not using 
utf8 (or ascii-only of course)", since we use UTF8 to read desktop files unless
an Encoding is specified.

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