This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114219/ |
On November 30th, 2013, 1:45 a.m. CET, Thomas Lübking wrote:
kcontrol/krdb/krdb.cpp (Diff revision 1) static void applyGtkStyles(bool active, int version)102 QString value = QFile::encodeName(list.join(":"));102 QString value = list.join(":");QFile::encodeName() seems equal to QString::toLocal8Bit(), ::decodeName() to ::fromLocal8Bit() I don't think one can just drop one of them and whether transcoding is required probably depends on what is done to the string interim. If at all "KToolInvocation::klauncher()->setLaunchEnv()" would perform a second decode, so it probaly depends on what that does. Was "locale charmap" determined by the reporter in the bug? --- Secret world domination plan: ------------------------------ #1: classified #2: classified #3: force ASCII as global standard #4: classified #5: classified #6: classified #7: classified #8: classified #9: classified #a: classifiedOn November 30th, 2013, 2:14 a.m. CET, Yichao Yu wrote:
encodeName/toLocal8Bit is used to encode a unicode string to a c-string/byte-array representation and decodeName/fromLocal8Bit does the reverse. The proper decoding is already done in QFile::decodeName above and the QString already has the right unicode string in it. Basically, QString is not a wrapper of arbitrary c-string/byte-array, rather a wrapper of a unicode string so whatever done to a QString before or after should assume it is a valid unicode string and is independent of what encoding (utf8 in the case of dbus) is needed afterward. Encode to a byte array and cast it back can only cause wrong encoding in the second conversion and will not affect what is done in setLaunchEnv.On November 30th, 2013, 2:20 a.m. CET, Yichao Yu wrote:
Or in another word QString has no encoding (well, by which I mean the internal encoding is trasparent to the user), only byte array and c-string has encoding.On November 30th, 2013, 2:53 a.m. CET, Thomas Lübking wrote:
QString(QByteArray) according to the API doc actually differs between Qt4 & 5 (fromAscii -> fromUtf8) but an encoding should not happen nevertheless because: 282 void KLauncher::setLaunchEnv(const QString &name, const QString &value) 283 { 284 #ifndef USE_KPROCESS_FOR_KIOSLAVES 285 klauncher_header request_header; 286 QByteArray requestData; 287 requestData.append(name.toLocal8Bit()).append('\0').append(value.toLocal8Bit()).append('\0'); Also QString(QByteArray) is obvisouly problematic by itself for the apparent 4/5 "incompatibility".On November 30th, 2013, 3:13 a.m. CET, Yichao Yu wrote:
I guess you can also put it in this this way (setLaunchEnv have toLocal8Bit inside) although I still think the simplest way is to remember QString -- encode --> QByteArray, QByteArray -- decode --> QString and always to the necessary explicit conversion. That's why I hate hate hate this constructor. (and I've already fixed 3-4 bugs in KDE due to this constructor.) It might actually be helpful to compile KDE with it commented out and replace everything with explicit conversion.....On November 30th, 2013, 3:13 a.m. CET, Yichao Yu wrote:
I guess you can also put it in this this way (setLaunchEnv have toLocal8Bit inside) although I still think the simplest way is to remember QString -- encode --> QByteArray, QByteArray -- decode --> QString and always to the necessary explicit conversion. That's why I hate hate hate this constructor. (and I've already fixed 3-4 bugs in KDE due to this constructor.) It might actually be helpful to compile KDE with it commented out and replace everything with explicit conversion.....On November 30th, 2013, 3:13 a.m. CET, Yichao Yu wrote:
I guess you can also put it in this this way (setLaunchEnv have toLocal8Bit inside) although I still think the simplest way is to remember QString -- encode --> QByteArray, QByteArray -- decode --> QString and always to the necessary explicit conversion. That's why I hate hate hate this constructor. (and I've already fixed 3-4 bugs in KDE due to this constructor.) It might actually be helpful to compile KDE with it commented out and replace everything with explicit conversion.....On November 30th, 2013, 3:15 a.m. CET, Yichao Yu wrote:
ahh.... sth wrong with my network.... sorry for the duplicated post...
I just had a look at the history of the specific line of code and tracked it back to "This commit was manufactured by cvs2svn" (238ffd07). The original line was: QCString value = QFile::encodeName(list.join(":")); doing several porting conversions via at one step QByteArray to finally QString. Given that it used to be a QByteArray the ::encodeName seems reasonable, but since it's QString I think that it's save to drop it.
- Martin
On November 30th, 2013, 5:38 a.m. CET, Yichao Yu wrote:
Review request for kde-workspace, David Faure, Martin Gräßlin, and Hugo Pereira Da Costa.
By Yichao Yu.
Updated Nov. 30, 2013, 5:38 a.m.
Bugs:
327919
Repository:
kde-workspace
Description
Testing
Diffs
|