> On June 12, 2013, 6:38 p.m., Jarosław Staniek wrote: > > 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. > > Friedrich W. H. Kossebau wrote: > Thanks for reviewing and testing Jaros?aw. Did not think of string > manipulations in formulas. So seems they are done based on QByteArrays with > text bytes encoded in UTF-8. Alright, will play around some more and then > possibly rather change Plan to follow what Kexi has done, transforming > between QString and QByteArray in UTF-8 encoding, thus discoard this patch. > More tomorrow.
So changed now KPlato::ProjectAccess, which gets registered as script object, to pass all strings as QByteArray encoded in UTF-8, which fixed things for me. Committed as 3968004bf7497f9a187d6e5b93f6f01f60df1f5b thus discarding this patch (he, officially is yesterday's tomorrow already ;) ). Thanks again. - Friedrich W. H. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110965/#review34247 ----------------------------------------------------------- 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
