--nextPart6042939.0UyoYMfyuN
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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=20
> 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).
>=20
> 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=
).=20
And as its current maintainer, I am convinced that the API is just plain fl=
awed=20
today.

=2D-=20
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

--nextPart6042939.0UyoYMfyuN
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQBM0CaGM/XwBW70U1gRAtwCAJ4wicXNF+QA4K0DX9sdjhQZwq1mjQCcC1T7
0oiGuaspnradsAitQ/yKaf8=
=gdxT
-----END PGP SIGNATURE-----

--nextPart6042939.0UyoYMfyuN--