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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
