Replacement for Qt's Undo Framework
Aaron J. Seigo
aseigo at kde.org
Tue Apr 26 09:24:24 BST 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110426/6f446aa9/attachment.sig>
More information about the kde-core-devel
mailing list