[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    libplasma in 4.2: binary compatibility and moving to kdelibs
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2008-07-29 16:59:06
Message-ID: 200807291059.06939.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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


["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]