[Development] Deprecating QFile::encodeName/decodeName

João Abecasis joao.abecasis at nokia.com
Fri Jun 8 11:03:40 CEST 2012


Thiago Macieira wrote:
> On quinta-feira, 7 de junho de 2012 10.06.31, Oswald Buddenhagen wrote:
>> it's not a no-op as soon as we actually implement some escaping
>> mechanism.
>> as joao pointed out, it is all about applying the decoding and escaping
>> at the right layer - which is exactly when using posix file i/o
>> functions, and nowhere else. as soon as you start doing it with cmdline
>> args and the environment you are in workaround land, and that only
>> increases the mess (because you don't know what encoding the other side
>> uses - the only reasonable assumption is that it wants locale encoding
>> (because that would be the right thing to do)).
> 
> So you're saying that we don't need to pass these file names with broken 
> encoding to other applications, nor do we need to accept them in the command-
> line.

We're saying that if you rely on knowing what is a file name and what isn't when processing command line arguments, QProcess arguments and whatnot you've lost the game. You'll be preventively sprinkling these functions all over the place ensuring that the impact is much wider than file names and setting us up for failure in finding an escaping mechanism that works.

Whatever mechanism we come up with must survive the QString <-> local 8-bit conversion, otherwise it doesn't help. It forces *ALL* application developers to consider them for the functionality to be useful.

Careful use of setEncoding/DecodingFuncion may enable ONE application to be written that supports the "funny" paths (mostly on Linux). It doesn't solve the general problem. It doesn't help everyone.

This is the sort of API that while useful (it has a use), hurts more than it helps in the wider ecosystem. You'd need the world to behave to claim the feature as part of Qt.

> Maybe you'll want to revert this then: 
> https://codereview.qt-project.org/#change,22854

Yes, I think that is the wrong fix.

I +1'd because it would work by default and fix a real issue for the time being. As I was going away on extended leave I didn't want to be blocking the discussion, but did leave comments.

The change doesn't need to be reverted. Only the use of encodeName needs to be removed and NFD normalization added on Mac.

Cheers,


João




More information about the Development mailing list