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
