why kdelibs?

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101102/66d029ef/attachment.sig>