[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: activity API in experimental?
From: Chani <chanika () gmail ! com>
Date: 2010-10-28 10:08:01
Message-ID: 201010281208.02710.chanika () gmail ! com
[Download RAW message or body]
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
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic