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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
