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

Kuba Ober kuba at mareimbrium.org
Mon Oct 6 21:53:42 CEST 2014


On Oct 6, 2014, at 2:45 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Monday 06 October 2014 13:30:29 Kuba Ober wrote:
>>> 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.
> 
> We thought about that. The problem comes when you need to pass the file name 
> through other means besides the file management functions.
> 
> How do you write it to a file using QIODevice? How do you write it to a file 
> using QTextStream?

How about:

1. Byte-oriented system: QIODevice: output as if it were a QByteArray.
   QTextStream: output while bypassing any encoding, as if it were already encoded.

2. UTF-16 (Windows): the underlying data is QString already.

> How do you pass it on the command-line? Mind you, QProcess takes a QStringList 
> for arguments.

It look as if we’d need something like QPlatformString that’s a “thin” wrapper
around a QByteArray on unices, and around QString on Windows. QProcess would be
expanded to accept a QList<QVariant> and QList<QPlatformString> in addition to
QStringList.Of course QPlatformString would need to be handled by QVariant.

> What should QCommandLineParser do? Assume that all arguments a QFileName?

Not necessarily, but they’d be QPlatformString. A QPlatformString could be
decoded into a QString, but not implicitly converted into it. The parser would
need to be able to process those strings. I presume that they’d need to be
treated as “anything <128 is ASCII, anything above is left alone”.

> What happens when you display the file name for the user in a text edit? What 
> happens if the user edits the text?

Here there’s only one sane behavior: decoder errors are replaced with question
marks, *and* if there were no changes to the text, the original representation
is preserved. QTextEdit and friends would need to support both QString and
QPlatformString.

> Will we replace all of the QString-based API with QFileName instead? QPixmap, 
> QLibrary, QPluginLoader, etc.

Maybe not replace, but expand: anywhere a QString is taken for a file name,
a QFileName or QPlatformString would be accepted as well. I’d think that
QFileName or QFilePath could be publicly derived from QString to indicate intent,
but perhaps even that wouldn’t be necessary.

> And how will you teach people to concatenate using the correct functions, 
> instead of manipulating using QString?

There’d be no implicit conversions to/from QString, and it’d need to support
concatenation with ASCII.

> Also remember that everything is the opposite on Windows: the file names are 
> really UTF-16 and cannot be encoded in the locale's 8-bit encoding.

That’s why on Windows, it’d be QString all the way down even when we pretend
otherwise. It’s really Unix that’s the bastard child…


It’s pretty clear, I think, that for source compatibility all of the QString
filename APIs would need to be retained and perhaps deprecated when 6.0 comes by.

I’m thinking this could be made BC and done for some 5.x. I volunteer, but any
prototypes are still a month-two away at this point.

Cheers, Kuba


More information about the Development mailing list