Replace KDE_open macro (and others)

[Thiago Macieira]

Em Terça-feira 20 Janeiro 2009, às 06:56:29, Christian Ehrlicher escreveu:
> Christian Ehrlicher schrieb:
> <snip>
>
> >> I can see how QString is a bad choice for paths - Thiago had the utopia
> >> that everyone would be using UTF-8 by now :-) ... but then the right
> >> choice is QByteArray IMHO, not QUrl... Of course the issue is how to put
> >> the right stuff into the bytearray, especially now that everything
> >> everywhere is using QString for paths. Even QUrl::toLocalFile(), BTW...
> >>
> >> Seems to me that proper support for this can only be done in Qt 5....
> >
> > I don't care if we use QString or QUrl but QByteArray is completly wrong.
>
> To be more clear - QByteArray isn't bad at all but not optimal.
> QFile::encodeName() returns a locale-encoded string which is wrong. It
> would be better to use QString::toUtf8() but this would mean that we (on
> windows) have to convert it back to a QString which makes it really slow.

No, you were right: QByteArray is completely wrong on Windows. If we use the 
locale encoding (on Windows, it's called "ANSI"), then we can't open files 
whose names are outside the locale. If we use UTF-8, then we have to be 
careful not to pass those byte arrays to other programs or in other contexts, 
since they may try to open using the ANSI functions and will then fail.

No, the proper solution is to use QString and to NEVER use QFile::encodeName 
on Windows.

Of course, on Unix, the situation is the reverse: ALWAYS use 
QFile::encodeName. But the moment that you use QString, then you can't open or 
deal with files whose names fall outside the locale encoding, since they can't 
be represented in QString in the first place (since Qt 4.3).

So, if we say:
1) KDE 4 *only* works in UTF-8 on Unix systems
and
2) Opening of or dealing with non-UTF-8 files is NOT supported with KDE 4 apps

then we can use QString in KDE_open. 

Interestingly that is, in fact, this is what are already doing. See WONTFIX 
bug 165044 [Dolphin can't handle well files/folders with wrong encoding].

All distributions I've seen ship with UTF-8 locales by default, even though 
some may give the option to switch non-UTF-8. Windows supports Unicode 
filenames since 1995, with the VFAT filesystem which most floppies and USB sticks 
use. Mac's filesystem is UTF-8 only (though they prefer NFD instead of NFC).

The problem is when you get Unix filesystems from 10 years ago (CD-ROM with 
Rock Ridge possibly; I think Joliet is Unicode), or if you try to open a 
tarball / zip files created by tools that don't encode in UTF-8. Those tools 
should be shot in the head.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Software Engineer - Nokia, Qt Software
  Qt Software is hiring - ask me
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090120/d7176ec3/attachment.sig>