activity API in experimental?
Chani
chanika at gmail.com
Thu Oct 28 12:08:01 CEST 2010
so... I'm starting to get people asking how they can use the activity API in
applications - and in one case, in kdelibs.
on the one hand, I really want to help them get started on that, I want to
have people using the API, giving feedback, and implementing awesome features
:)
on the other hand... it's still changing, it's not ready for BC at all. it's
experimental. Ivan's going to be making several changes to it this week, in
fact.
I *could* tell them about the raw dbus interface (for which the api -
KActivityConsumer and friends - is just a helpful wrapper), but that feels...
icky. It's just as prone to change (only the errors wouldn't cause crashes, I
suppose) and they'd have to rewrite it to use KActivityConsumer later.
we could, perhaps, move KActivityConsumer into kdelibs/experimental? if it's
not too late? that would expose it without BC requirements (although the guy
wanting to use it in kdelibs still couldn't, I expect?). I can't remember the
exact implications of kdelibs/experimental, but
http://techbase.kde.org/Policies/New_KDE_Library_API_Policy seems to imply
that we just move it in there like moving to kdereview, and the only
requirements are to version the library properly and have a cmakelists that
can build it as its own project.
so, which is better for early adopters, a dbus interface or an experimental
API? I'm leaning towards experimental, since it'll be less work for them to
update their patches when the api does become stable.
--
Chani
http://chani.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101028/25104ebe/attachment.sig
More information about the Plasma-devel
mailing list