[Development] Backwards compatibiltiy break in Qt 5.5

NIkolai Marchenko enmarantispam at gmail.com
Mon Jul 27 00:25:18 CEST 2015


(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 HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/development/attachments/20150727/330ce5f7/attachment.html 


More information about the Development mailing list