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