--nextPart2507838.8z9kY2dbBM
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

On Tuesday, April 26, 2011 07:12:32 Tom Albers wrote:
> It does sound like to me as we take the base class from Qt and
> improve it for usage within KDE. 

not if it can be improved directly in the classes in Qt itself, limiting the 
number of classes we have, lowering the cost of learning the combined Qt+KDE 
API and ensuring we don't end up with yet more stories of Qt implementing 
something today that was done in kdelibs a year ago as a subclass of a Qt 
class.

> We've done that for years and years.

yes, because Qt was generally closed to external development and we didn't 
consider it a valid development target. this has changed, and the "put it into 
kdelibs" practice also had its costs, however. we now have the opportunity to 
improve on this historical practice, so perhaps we should try to do so.

> Does
> this now imply that that's bad practice and kdelibs is closed for such
> classes?

it's bad practice if it can be fixed in Qt; it's not bad practice if it is 
something that doesn't belong in Qt. kdelibs should be a value-add extension 
of Qt for areas that make sense primarily/exclusively to the kinds of apps we 
create and/or target. it should not be a collection of bug fixes or minor 
improvements to Qt.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

--nextPart2507838.8z9kY2dbBM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAk22gT0ACgkQ1rcusafx20PgigCgirrsv0alYflBl2Pd4n5RtF34
UuQAn1c2Bx/Sf0/DTjcCtoqavSMdg50B
=PJjt
-----END PGP SIGNATURE-----

--nextPart2507838.8z9kY2dbBM--