New Krazy check: Forbidden Qt classes

[David Faure]

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.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).