Ok, I cleaned this up, redid it basically with the suggestions from this thread.  I put a review request on reviewboard, and the code is in kdelibs whiting/buildwithqt48 branch.<br><br>Enjoy,<br>Jeremy<br><br><div class="gmail_quote">
On Mon, May 2, 2011 at 11:37 AM, Olivier Goffart <span dir="ltr"><<a href="mailto:ogoffart@kde.org">ogoffart@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Le Monday 02 May 2011, David Faure a écrit :<br>
<div class="im"><br>
> Another one:<br>
><br>
> -      envs << QString::fromLatin1( QByteArray("DISPLAY=") + dpystring );<br>
> +    envs << QString::fromLatin1( QByteArray(QByteArray("DISPLAY=") +<br>
> dpystring) );<br>
<br>
</div>Should be QLatin1String("DISPLAY=") + QLatin1String(dpystring)<br>
(Assuming dpystring is char*)<br>
<div class="im"><br>
<br>
><br>
> Is this still because QString::fromLatin1( const QByteArray& ) is missing,<br>
> so it has to cast to const char* here too? Olivier, wouldn't it make sense<br>
> to have such an overload? (It would save a strlen, too).<br>
<br>
</div>Yes, maybe  QString::fromLatin1(const QByteArray&) would make sens<br>
But it might brake source compatibility if the call becomes ambiguous.<br>
<br>
The reason why we brake source compatibility with QT_USE_FAST_OPERATOR_PLUS is<br>
because this one was not documented.  But maybe the new operator should only<br>
be enabled if QT_USE_FAST_OPERATOR_PLUS is defined to 2 or something.<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>