[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Kuba Ober]

On Oct 7, 2014, at 6:11 AM, Tomasz Siekierda <sierdzio at gmail.com> wrote:

> On 7 October 2014 11:16, Marc Mutz <marc.mutz at kdab.com> wrote:
>>> Ugh, that begins to sound like Java. Let's have a wrapper for a
>>> wrapper... please don't go that way.
> 
>> We have QSize and QPoint and they're used ubiquitously in Qt. But, by your
>> rationale, everyone should be using two ints instead, so let's remove them!
> 
>> How's that anything to do with Java? C++ is made from the ground up for
>> lightweight abstractions such as a size, a point and a file path. It's Java
>> that isn't.
> 
> QSize, QPoint, QRect, etc. are useful, very convenient, intuitive and
> a good thing to have. For file paths, I feel QString is really enough.
> Changing it to something else because of a few corner cases seems like
> an overkill to me. 

Just to be very clear: it is currently impossible to make a truly portable file management utility with Qt’s core APIs. Why? Because it will simply ignore all file names that it can’t decode when iterating the directory, and it won’t be able to take commandline arguments to open such files either. Furthermore, this is something that very basic C code using nothing but POSIX APIs can trivially deal with. Or that Python 2 trivially deals with. I consider it a serious enough problem.

The problem is serious enough, indeed, that Python 3 has resorted to a hack where they use a private Unicode range to encode the bytes between 128 and 255 in strings that fail normal decoding. I think that putting this hack into QString is unthinkable, and the concept of a platform string has to be taken with heads up and in a manner that will make it useful, usable and unobtrusive. I don’t claim that it’s a trivial task, but then I’m not asking anyone else but myself to deal with it :)

Cheers, Kuba