----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110965/#review34247 -----------------------------------------------------------
Thanks for testing this Friedrich, Unfortunately this patch reverses my patch for unicode string constants as well as unicode values. You can try to recreate report like on this screenshot: http://wstaw.org/m/2013/06/12/plasma-desktopup8006.png On the same screenshot you see the broken result. More investigation is needed. - Jarosław Staniek On June 11, 2013, 11:25 p.m., Friedrich W. H. Kossebau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110965/ > ----------------------------------------------------------- > > (Updated June 11, 2013, 11:25 p.m.) > > > Review request for Calligra, Sebastian Sauer and Jarosław Staniek. > > > Description > ------- > > How to see the symptom which hopefully is fixed at its root: > 1. Start Plan, create a new project from the Simple->Plain template > 2. Click "Edit Main Project" > 3. Enter some non-latin1 text for the Name: and Manager: fields, close dialog > with Okay > 4. Select the view "Task Status Report" (last in list in docker) > 5. See how the non-latin1 characters are wrongly rendered at the top of the > report page. > > I could not find in any documentation that the result of > Kross::Action::evaluate() can not be simply converted into a QString, but > instead needs to be converted to a QByteArray and then converted via > QString::fromUtf8. > > KPlato::ReportWidget::slotRefreshView() registers KPlato::ProjectAccess as > script object which feeds "Name" and "Manager" as QString, not encoded into > QByteArray. Thus the attached patch fixes the above behaviour. > > Jaros?aw, you introduced that behaviour in > 8694fc63ae51f2f6f89514d5816187d8907cf2a5 as fix for > https://bugs.kde.org/show_bug.cgi?id=277731 > But I think you misunderstood Sebastian, he possibly only meant to do the > explicit conversion for the "code" parameter, not the result. So this patch > also undoes that explixit conversion to QByteArray if a string in > KRScriptFunctions::value(...). > > Sebastian, can you confirm that only the parameter "code" needs to be given > as QByteArray text (in UTF-8 encoding), while the QVariant result of the > method should contain normal QStrings if those are the result of the > evaluation? > > > Diffs > ----- > > kexi/plugins/reports/krscriptfunctions.cpp b25b92d > libs/koreport/renderer/scripting/krscripthandler.cpp 833f4f3 > > Diff: http://git.reviewboard.kde.org/r/110965/diff/ > > > Testing > ------- > > > Thanks, > > Friedrich W. H. Kossebau > >
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
