On 17 Apr 2023, at 18:16, Thiago Macieira <thiago.macie...@intel.com> wrote:
>> But anything that goes through QIODeivce::read or write (QProcess,
>> QFile, Q{Udp,Tcp,Local}Socket) will suffer if there's no agreement on
>> what that encoding is.
And that's a cross-platform problem for anyone who has to consume data
produced by a (presumably non-Qt) source that's using legacy codecs.
At present our answer is to use Qt-with-ICU or some separate codec-converter.
>> [snip] What has changed is that the Windows API has matured to the
>> point that this is now a viable choice (previously, it was
>> experimental and known to cause issues). But it's still an
>> application choice; we can't enforce it.
But we *can* document how to do it as part of our "how to package your
application" instructions, thereby encouraging users of Qt to do so.
>> But I think we should:
>> a) do it for our own applications, since we do know our own code
>> b) advise users somehow that they should opt-in to this
>> c) decide if we want to change from opt-in to opt-out in the medium
>> term (7.0 for example)
>> d) decide if we want to enforce it in the long-term
>>
>> Option (d) depends on (c). Option (c) informs whether we need a Qt
>> CMake API or whether we can simply say upstream CMake should handle
>> it.
Lars Knoll (18 April 2023 09:46) replied
> I think this should be the goal, but I’d vote for a slightly faster
> schedule.
>
> (a) and (b) are things we should be able to do right now.
Sounds sensible to me.
Eddy.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
