--===============4516032924180086313== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > On Nov. 30, 2013, 1:45 a.m., Thomas Lübking wrote: > > kcontrol/krdb/krdb.cpp, line 102 > > > > > > 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: classified > > 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. > > > 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. > > > 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". > > 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..... > > > 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..... > > > 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..... > > > 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 ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114219/#review44857 ----------------------------------------------------------- On Nov. 30, 2013, 5:38 a.m., Yichao Yu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/114219/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2013, 5:38 a.m.) > > > Review request for kde-workspace, David Faure, Martin Gräßlin, and Hugo Pereira Da Costa. > > > Bugs: 327919 > http://bugs.kde.org/show_bug.cgi?id=327919 > > > Repository: kde-workspace > > > Description > ------- > > list.join already returns a QString and there is no need to encode it and cast back to QString again.... > > P.S. for a patch that applies to both KDE4 and KF5(master for kde-workspace, frameworks for kdelibs?) How should I submit review request? Should I add both in branch or submit two review request? (But often the patch cannot apply directly due to context or file path changes). > > > Diffs > ----- > > kcontrol/krdb/krdb.cpp 92d84e9 > > Diff: http://git.reviewboard.kde.org/r/114219/diff/ > > > Testing > ------- > > Compiles. > Fixes the problem here. > > > Thanks, > > Yichao Yu > > --===============4516032924180086313== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit
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: classified

On 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 

list.join already returns a QString and there is no need to encode it and cast back to QString again....

P.S. for a patch that applies to both KDE4 and KF5(master for kde-workspace, frameworks for kdelibs?) How should I submit review request? Should I add both in branch or submit two review request? (But often the patch cannot apply directly due to context or file path changes).

Testing 

Compiles.
Fixes the problem here.

Diffs

  • kcontrol/krdb/krdb.cpp (92d84e9)

View Diff
--===============4516032924180086313==--