Full support from my side for it. Cheers, Lars
On 5/14/12 1:11 PM, "ext Thiago Macieira" <[email protected]> wrote: >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 >_______________________________________________ >Development mailing list >[email protected] >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
