On Oct 6, 2014, at 11:21 AM, Thiago Macieira <thiago.macie...@intel.com> wrote:

> On Monday 06 October 2014 11:12:57 Kuba Ober wrote:
>> Thus, how does Qt deal with a directory listing with such “invalid” file
>> names? Do they survive the round-trip through a QString and QDirIterator?
>> Would it be worthwhile to tackle this issue in a better fashion (whatever
>> it might be) for Qt 6?
> 
> File names that cannot be decoded using the locale codec are considered 
> filesystem corruption and are silently dropped. They won't appear in 
> directory 
> listings.
> 
> This was discussed to exhaustion in Qt 5's development process. The 
> conclusion 
> is to remain at status quo since there is no good, technical solution.

I’d think that the solution could be to use a dedicated class for file names, 
perhaps with a base class for uninterpreted platform strings. One would also 
need to think about console I/O, since no matter what the encoding is, it’d be 
nice to remain somewhat at the level of what bare C provides. For example, a C 
program doesn’t need to know the encoding of file names nor the encoding used 
by the console - as long as they are one and the same, printing file names will 
“just work”. That’s of course assuming that the encoding is ASCII-compatible.

So, I’m specifically thinking of:

1. Retaining platform-specific representation of a file name in a class like 
QFileName (it’d be a QString wrapper on Windows, for example).

2. Sending it out to `QTextStream(stdout)`, and inputting it from 
`QTextStream(stdin)`.

3. Using the platform representation in addition to visible representation in 
the filesystem model.

Would something like that have any chance of getting accepted into Qt 6, if 
done “properly”? Obviously I haven’t thought out the details yet and there may 
be a need for several prototypes before it turns into anything remotely 
acceptable.

Cheers, Kuba
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to