[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Thiago Macieira]

On Sunday, 17 November 2019 01:55:32 CET Thiago Macieira wrote:
> I don't know why QTextCodec is being removed. I don't remember any decisions
> in prior QtCS or this mailing list about removing it. We definitely
> discussed removing the CJK codecs and their big tables and that can still
> be done, with no effect in the API, since QTextCodec is backed by ICU's
> ucnv. We may have discussed removing it, but I don't remember a firm
> decision. And even if it is firm, after looking at the consequences of
> doing so, we may want to reverse our decision.

Update: after talking to Lars during QtCS, he said that he thinks the 
QTextCodec API is poorly designed and should be replaced. I agree. But that 
doesn't mean we need to remove the *functionality*, just deprecate the API.

I'll bring this up during the QtCore session tomorrow to see if we want to 
invest time creating a new API, hopefully for 5.15, so code can begin porting 
before the 6.0 time. That way, we could move QTextCodec out of QtCore.

> 1) QTextCodec in the API
> I think we cannot do without it, it'll have to stay in one way or another.
> So the question reduces to whether it should stay in QtCore or be moved to
> another library. Given the QXmlStreamReader problem above, it's probably
> best to keep it in QtCore, actually.
> 
> QTextCodec has some API limitations but they can be fixed. It's not
> necessary for us to remove it: it's not *that* broken.

This is now TBD, depending on finding a good design and whether it can be done 
incrementally in QTextCodec.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products