[Development] Deprecating QFile::encodeName/decodeName

[lars.knoll at nokia.com]

Full support from my side for it.

Cheers,
Lars

On 5/14/12 1:11 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
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
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development