Hi,
unfortunately, we did not manage to get a QStringConverter backend based on ICU
into Qt in time for FF
(https://codereview.qt-project.org/c/qt/qtbase/+/393373). This is a feature
strongly requested by KDE as an enabler
for their KDE Frameworks 6 port [1] and from various users in APAC, where
non-UTF codecs like Shift JIS still have some
popularity.
What remains to be done:
- There are concerns that mixing Qt versions might lead to an unbounded memory
leak with the current implementation.
I don't think that's actually the case (but if it is, then we need a
different enough approach that this most likely has to be
deferred to Qt 6.5 at least).
- Testing uncovered that there's an issue with writing out replacement
characters, causing infinite recursion under certain
circumstances. That needs to be fixed, but should hopefully be easy by
checking and mirroring how ICU's own replacement
callback works.
- Thiago (rightfully) requested more test cases; I'm cautiously optimistic that
those won't uncover any further issues.
Impact on other parts of Qt and 6.4 API review
- The base patch will not introduce any new public API, it just extends what is
possible with the existing API.
- The follow-up patch will introduce one new function; and make use of the new
ICU backend in a few places in Qt, which
before would have rejected the incoming data.
Expected additionally needed time:
I expect that the remaining work can be completed by the end of next week.
Given the above, would it be possible to grant a feature freeze exemption until
end of next week for this feature?
Regards,
Fabian
[1] KDE has to support legacy codecs in e.g. their text editor(s).
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
