New Krazy check: Forbidden Qt classes

[Allen Winter]

On Wednesday 25 April 2007 7:19:06 pm 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.
> 

Then I should add QUrl to the "prohibited Qt classes" list??

BTW: the check only looks in *.cpp files.
Which reminds me... it's ok for kdialog.cpp to use QDialog.  whoopsie