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" <[email protected]> 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. >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
