libplasma in 4.2: binary compatibility and moving to kdelibs

[Aaron J. Seigo]

hi all...

so 4.2 is here and the Big Questions come with it:

Binary Compatibility
============
 should we break binary compatibility one last time? if so that means we can:

	* do one more API review (though it won't be nearly as drastic as the one in 
4.1)
	* add some of the new features that are coming in 4.2 in a more natural way. 

and example of "more natural" is having a virtual initExtenderItem in Applet; 
that's a binary incompatible change, and the alternative is to put it in 
Extender (a new class) and make people subclass that. however, it would be 
less comfortable that, imho.

Where Does It Live?
============

moving libplasma into kdelibs was a goal we stated for 4.2 back when figuring 
out what 4.1 would be. i'd like to see this happen still as it would allow 
more applications to use libplasma in more interesting ways.

the Package* classes may want to move into khotnewstuff ... that's something 
we'd need to examine.

ConfigXml really ought to be in libkdeui alongside KConfigSkeleton imho. (kdeui 
because it uses QColor; perhaps we could manage to shove it into kdecore using 
QVariant cleverly? hm.)

-- 
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 Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080729/6d73b89d/attachment.pgp