[Development] Deprecating QFile::encodeName/decodeName

[Thiago Macieira]

I'd like to deprecate those two functions, as well as the setters 
QFile::setEncodingFunction and setDecodingFunction. I'd like to go further and 
make the setters no-op, and the actual functions be just an inline wrapper for 
QString::to/fromLocal8Bit. However, I'll leave the encode/decodeName functions 
as part of the Qt 5 API.

Rationale:

Those two functions have been present in Qt since at least Qt 2 (see [1] and 
[2]). Their purpose was to convert the UTF-16-based QString filenames to the 
local filesystem encodings on Unix systems. Back in those days, some people had 
file names encoded with a different encoding than the locale -- for example, 
UTF-8 for the file names and Latin 1 or 15 for the data, or vice versa.

For that reason, Qt developers should use QFile::encodeName when converting a 
QString for use in the POSIX C function calls, and similarly use 
QFile::decodeName when converting data from the POSIX calls to QString.

That concept is broken.

The POSIX calls are not the only source of strings. There are more, like for 
example the command-line and data found in files. When parsing the command-
line, QCoreApplication applies QString::fromLocal8Bit indiscriminately, since 
it doesn't know which arguments refer to files and which ones don't. If you're 
reading from a file, you're likely to do the same or to use QTextStream, which 
amounts to the same problem. 

Moreover, if you're going to print a file name to a file, what do you use? When 
communicating with other programs, what encoding should be used? How about 
reporting information on the terminal (stdout and stderr)? Similar to 
QCoreApplication, when you set file names as part of the arguments in QProcess 
indiscriminately applies toLocal8Bit, since it doesn't know what is a file name 
and what isn't.

Therefore, I call this concept broken. There's only one possible encoding for 
the file system and it's the locale's encoding.

I will make the change and submit for approval. I will not wait for the 
discussion on the mailing list because, quite frankly, I do not expect anyone 
to disagree. 

If you *do* disagree, please speak up and make sure you have very convincing 
arguments on why we should keep this functionality and how developers should 
address the problems I described above. If the community agrees to leaving 
them, we can revert my patches.

[1] http://doc.trolltech.com/2.3/qfile.html#6d63a6
[2] http://doc.trolltech.com/3.3/qfile.html#encodeName
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120514/73bbb79b/attachment.sig>