[Development] FW: Backwards compatibiltiy break in Qt 5.5

[Knoll Lars]

Hi,

I can understand the issues that non latin speakers are facing with this
well. I’ve often used qDebug() to debug non latin use cases, and in 90% of
the cases I just want to know what the string reads. The unicode content
of it is interesting to me in only 10% of the cases. For most users not
debugging Qt’s internals I would assume that ratio to be more like 99 to 1.

Thiago, which backends can’t handle utf8 or utf16 output these days?

One idea could be a slightly modified approach that is more compatible:

* We always encode QStrings as utf8 (maybe utf16 for the windows console)
when sending them to qDebug()
* We quote every character that is not printable (ie. !QChar::isPrint())
* We add a flag that would give fully quoted strings so you can get a
quoted version if required (e.g. qDebug() << quoteStrings)

Could such an approach work in practice?

Cheers,
Lars


On 27/07/15 00:25, "NIkolai Marchenko" <enmarantispam at gmail.com> wrote:

>(I am not entirely sure why I haven't received at least a notification of
>why this post has not appeared the first time I tried to send it, so here
>we go again. Btw, it was Thiago Macieira himself who actually suggested I
>mail this list)
>
>
>
>
>Hi! We (Russian Qt community) have a situation we could not resolve with
>Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's
>attention.
>The bug in question is there:
>https://bugreports.qt.io/browse/QTBUG-47316
>
>
>In version 5.5 Thiago Macieira introduced a compatibility break with
>older qt versions.
>This break has come in the form of completely changing the way qDebug()
>prints non-english characters to console.
>
>
>In essense - his "fix" to qDebug() will make it so that all non-english
>output from QString variable to qDebug()
>will be passed as a sequence of unicode escaped characters along the
>lines of:
>
>
>"\u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430
>043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B"
>
>
>Previously, in _some_ cases, but not reliably cross platform it would
>actually appear in console as readable output in user's language.
>I have to admit that Thiago is right about it being non-reliable
>contradicts qt's goal. Still...
>
>
>What Thiago completely disregards as unimportant - qDebug()'s been around
>for a looooong time. Even during times of qt4, users,
>through the use of setCodec functions, achieved readable output from
>qDebug in the console in their native language.
>Note that I say qt4. It's been around for almost a decade and there being
>no warning qDebug ever changing, it's become a standard
>on a lot of non-english installations, that actually allowed getting
>readable output, to use qDebug for tracing variables..
>After all, opening debugger to inspect every little thing is very
>counterproductive.
>
>
>So here is where we are now, there are hundreds (probably thousands
>actually) codebases, where there is code like that:
>qDebug() << someLabel;
>// skip
>qDebug() << someVariableFromDatabase;
>// skip
>qDebug() << someTextFromNetworkService;
>
>
>This is kinda normal and completely adhering to Kai Kohne's message he
>posted on youtube in qt-dev days video
>of using qDebug() to log program execution to console. Now, we arrive to
>Qt5.5. From here on now, instead of reading the trace of
>program execution everyone using the old code will be subjected to
>strings like
>
>
>\u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430
>043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B
>
>
>Note, that there are dozens to hundreds of such lines per application.
>And in SUCH a format,
>the trace posted above becomes completely useless for the purposes of
>debugging,
>because people, generaly, don't have unicode parser plugged into their
>brains.
>
>
>Thiago argues that his way, user will always get exactly which type of A
>the symbol is.
>Our point - now user will first need to pass the output of qDebug to
>unicode converter to even understand what's he looking at.
>
>
>Now, again, I do not dispute that qDebug in a way it was being used was
>correct or reliable across all platforms or allowed to check exactly
>which 
>symbol was contained in a string. But BETTER way to fix that, in my
>opinion, and all of the Russian users who are already aware of the problem
>is to introduce a qDebug().escape() or something along those lines, in
>those RARE cases when instead of just tracing variables, user NEEDS to
>see unicode.
>
>
>(note I say "Russian", because that is the community I come from, but in
>reality the situation is the same for greek, japanese, whatever
>non-english)
>
>
>Here we have a conflict of interest: "Do we fix qDebug() in a way it is
>SUPPOSED to work, breaking code for users, or do we make a different
>flavour 
>of qDebug that actually works as we intended it to, cross platform and
>escapes everything and let people who need it switch to that?"
>
>
>Personally, from what I know of application development, breaking
>codebase is always bad. breaking a LARGE codebase, is horrible.
>So, I am at a loss of why Thiago decided to go the first way. We've tried
>to convince him he underestimates the potential harm to customers of Qt,
>but he refuses to listen insisting that if ppl used qDebug() incorrect,
>they are not entitled to their code not breaking at any moment he seems
>fit to fix it. But the point is - how were we to know we were using
>qDebug() incorrectly, when nothing along those lines were EVER posted on
>qDebug()'s help page?
>
>
>People relied on the way it's worked before.
>No one warned peope, about the change.
>The change is not even backwards compatible to older qt versions.
>
>
>As Thiago refuses to admit there is a problem, we have to ask the
>authorities behind Qt to look into this.
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150727/81c662ee/attachment.txt>