Trash spec 0.4
alexl at redhat.com
Thu Sep 9 20:29:21 EEST 2004
On Thu, 2004-09-09 at 18:19 +0200, David Faure wrote:
> On Thursday 09 September 2004 15:12, Alexander Larsson wrote:
> > > 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?
Ah, that depends on what you mean by "works". Nautilus correctly
separates the "display name" (utf8 string) from the actual filename
(byte array), and uses various ways to try to come up with the display
version of the filename.
If you're using utf8 filenames (this is an env var setting, where utf8
is the default), if the filename doesn't validate as utf8, we first try
to convert it from the locales encoding and if that fails we convert
utf8->utf8 replacing all invalid sequences with '?' and add " (invalid
unicode)" to the end.
This is used for the display name so you can show the file at all in the
UI. But, when you for instance rename the file (so its correct utf8) or
delete it, the real filename is used, not the display name. So,
everything works perfect for utf8 files, and you can manage invalidly
encoded files fine, although they might display slightly strange.
If you force conversions of filenames to utf8 you won't be able to
manage invalidly encoded files at all.
> > 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...
That would be UTF8 almost all the time for Gnome then, but many existing
filenames are not valid utf8, and can thus not be trashed.
> 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 :)
Surely there must be a byte-array type in Qt?
Alexander Larsson Red Hat, Inc
alexl at redhat.com alla at lysator.liu.se
He's an immortal ninja master criminal living undercover at Ringling Bros.
Circus. She's a time-travelling wisecracking museum curator with an incredible
destiny. They fight crime!
More information about the xdg