<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/110965/">http://git.reviewboard.kde.org/r/110965/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 12th, 2013, 6:38 p.m. UTC, <b>Jarosław Staniek</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On June 14th, 2013, 10:55 p.m. UTC, <b>Friedrich W. H. Kossebau</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
<br />
<p>- Friedrich W. H.</p>
<br />
<p>On June 11th, 2013, 11:25 p.m. UTC, Friedrich W. H. Kossebau wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Calligra, Sebastian Sauer and Jarosław Staniek.</div>
<div>By Friedrich W. H. Kossebau.</div>
<p style="color: grey;"><i>Updated June 11, 2013, 11:25 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kexi/plugins/reports/krscriptfunctions.cpp <span style="color: grey">(b25b92d)</span></li>
<li>libs/koreport/renderer/scripting/krscripthandler.cpp <span style="color: grey">(833f4f3)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/110965/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>