<div dir="ltr"><div>(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)</div><div><br></div><div><br></div><div>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.</div><div>The bug in question is there:</div><div><a href="https://bugreports.qt.io/browse/QTBUG-47316">https://bugreports.qt.io/browse/QTBUG-47316</a></div><div><br></div><div>In version 5.5 Thiago Macieira introduced a compatibility break with older qt versions.</div><div>This break has come in the form of completely changing the way qDebug() prints non-english characters to console.</div><div><br></div><div>In essense - his "fix" to qDebug() will make it so that all non-english output from QString variable to qDebug() </div><div>will be passed as a sequence of unicode escaped characters along the lines of:</div><div><br></div><div>"\u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B"</div><div><br></div><div>Previously, in _some_ cases, but not reliably cross platform it would actually appear in console as readable output in user's language.</div><div>I have to admit that Thiago is right about it being non-reliable contradicts qt's goal. Still...</div><div><br></div><div>What Thiago completely disregards as unimportant - qDebug()'s been around for a looooong time. Even during times of qt4, users,</div><div>through the use of setCodec functions, achieved readable output from qDebug in the console in their native language.</div><div>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</div><div>on a lot of non-english installations, that actually allowed getting readable output, to use qDebug for tracing variables..</div><div>After all, opening debugger to inspect every little thing is very counterproductive.</div><div><br></div><div>So here is where we are now, there are hundreds (probably thousands actually) codebases, where there is code like that:</div><div>qDebug() << someLabel;</div><div>// skip</div><div>qDebug() << someVariableFromDatabase;</div><div>// skip</div><div>qDebug() << someTextFromNetworkService;</div><div><br></div><div>This is kinda normal and completely adhering to Kai Kohne's message he posted on youtube in qt-dev days video</div><div>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 </div><div>program execution everyone using the old code will be subjected to strings like</div><div><br></div><div>\u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B</div><div><br></div><div>Note, that there are dozens to hundreds of such lines per application. And in SUCH a format,</div><div>the trace posted above becomes completely useless for the purposes of debugging,</div><div>because people, generaly, don't have unicode parser plugged into their brains.</div><div><br></div><div>Thiago argues that his way, user will always get exactly which type of A the symbol is.</div><div>Our point - now user will first need to pass the output of qDebug to unicode converter to even understand what's he looking at.</div><div><br></div><div>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 </div><div>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</div><div>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.</div><div><br></div><div>(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)</div><div><br></div><div>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 </div><div>of qDebug that actually works as we intended it to, cross platform and escapes everything and let people who need it switch to that?"</div><div><br></div><div>Personally, from what I know of application development, breaking codebase is always bad. breaking a LARGE codebase, is horrible.</div><div>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,</div><div>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</div><div>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?</div><div><br></div><div>People relied on the way it's worked before.</div><div>No one warned peope, about the change.</div><div>The change is not even backwards compatible to older qt versions.</div><div><br></div><div>As Thiago refuses to admit there is a problem, we have to ask the authorities behind Qt to look into this.</div></div>