On Saturday 30 October 2010, Marco Martin wrote:
>  * KUrl (and many similar examples): why the hell we still have a class
> like  that?

So that we didn't spend 2 man years on porting from KUrl's API to QUrl's API.
Consider it an abstraction which was ported to "its own slow parsing" in kde3,
to "QUrl's fast parsing (and extra strictness)" in kde4.

It also exists so that you don't fall into the QUrl API traps...
Would you say this code is correct?
  QUrl url3 = QUrl::fromLocalFile( "/home/dfaure/hash#file" );
  QString url3Str = url3.toString();
  QUrl url4(url3Str);
  QCOMPARE( url4.toString(), url3Str ); // passes
  QVERIFY( url3 == url4 ); // ...

Well, the QVERIFY fails. This is because toString() returns 
"file:///home/dfaure/hash#file" rather than "file:///home/dfaure/hash%23file".
So the roundtrip via QString using toString() messed up the URL.

It's arguably almost-documented (toString() says "human-readable", from which 
one might, if lucky, deduce that it's not suitable for putting back into a 
QUrl) but that's still very unexpected. QUrl users have to use 
toEncoded/fromEncoded for such conversion from/to QString (well, QByteArray) 
without loss, which is kind of unexpected, given the naming of the existing 
"toString" method (the "lossy" one)...

More generally, I would say QUrl's API tends to be "standards-conformant" 
(i.e. you need to be a url expert to use it properly) while KUrl's API shows 
10 years of experience of being used in a desktop with heavy url usage.

To get back to the point of this thread: ideally we wouldn't be in this 
situation, if indeed I could have actively participated in QUrl's development 
and ensured that it would match KDE's needs without quirky API. I did give 
feedback (about behavior; with unittests etc.), and bugs got fixed, but my 
feedback about the toString "trap" was dismissed as "you're not supposed to 
use it for putting back into a QUrl". Well, clearly... but this requires much 
URL knowledge, rather than being easy-to-use like KUrl (which can parse paths 
in the constructor and whose url() and prettyUrl() can both be put back into a 
KUrl again).

To conclude: I can see a huge long-term gain in merging kdelibs and Qt (while 
keeping maintainership of the things we care about!), but let's see how open 
Qt development can really become before we take any further steps.
Right now, contributing to Qt is still a major PITA, and external contributors 
are very obviously second-class citizens.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).