On Tuesday, 2 de November de 2010 05:34:12 David Faure wrote: > 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.
QUrl needs a rewrite of its internals (not the parsing, which is quite good). And as its current maintainer, I am convinced that the API is just plain flawed today. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.