Review Request 110965: fix broken conversion of results from koscript code evaluation in KRScriptHandler::evaluate()

[Friedrich W. H. Kossebau]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20130615/ba0882cc/attachment.htm>