New Krazy check: Forbidden Qt classes

[Sebastian Trüg]

On Thursday 26 April 2007 01:19:06 David Faure wrote:
> On Wednesday 25 April 2007, Kevin Ottens wrote:
> > IIRC a QUrl instead of KUrl in the public API could make sense, but I
> > don't remember the exact rationale.
>
> I strongly disagree. KDE code should use KUrl.
>
> QUrl has dangerous/broken(imho) API, e.g. QUrl::toString() gives a string
> that cannot be parsed back as a url (like we do in many many places with
> KUrl::url(), e.g. over DBus), because e.g. a '#' in the path will appear as
> a '#' in QUrl::toString(), and QUrl(thatstring) will see it as a reference.
> I'm told that's a feature and not a bug (toString is for pure user display,
> one should use toEncoded instead to get something that must be parseable
> again as a url), but I'm 100% sure we'll see lots of bugs popping up just
> because of this, (and because of QUrl(path)), if kde developers start using
> QUrl directly.
> Let's just use the KUrl API everywhere in kde, please. We benefit from all
> the good stuff in QUrl (fast parsing, validity checking), but we can do it
> with the proven API we have been using for a long time in kde.

Now this is really a problem. I did it the same way to pass QUrls over DBus as 
strings: 

QDBusArgument << QUrl.toString

and

QDBusArgument >> QString
QUrl(QString)

And that is apparently not the correct way, right?
So what am I to do then?

QDBusArgument << QString::fromUnicode(QUrl.toEncoded)

and

QDBusArgument >> QString
QUrl::fromEncoded( QString.unicode())
??

Cheers,
Sebastian