faure at kde.org
Tue Nov 2 12:34:12 GMT 2010
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();
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
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 at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the kde-core-devel