thiago at kde.org
Tue Nov 2 14:56:05 GMT 2010
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel