From kde-panel-devel  Thu Oct 28 10:08:01 2010
From: Chani <chanika () gmail ! com>
Date: Thu, 28 Oct 2010 10:08:01 +0000
To: kde-panel-devel
Subject: activity API in experimental?
Message-Id: <201010281208.02710.chanika () gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=128826048419574
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1878414570=="

--===============1878414570==
Content-Type: multipart/signed;
  boundary="nextPart1818328.Dd1DUgE1a5";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1818328.Dd1DUgE1a5
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

so... I'm starting to get people asking how they can use the activity API i=
n=20
applications - and in one case, in kdelibs.

on the one hand, I really want to help them get started on that, I want to=
=20
have people using the API, giving feedback, and implementing awesome featur=
es=20
:)
on the other hand... it's still changing, it's not ready for BC at all. it'=
s=20
experimental. Ivan's going to be making several changes to it this week, in=
=20
fact.

I *could* tell them about the raw dbus interface (for which the api -=20
KActivityConsumer and friends - is just a helpful wrapper), but that feels.=
=2E.=20
icky. It's just as prone to change (only the errors wouldn't cause crashes,=
 I=20
suppose) and they'd have to rewrite it to use KActivityConsumer later.

we could, perhaps, move KActivityConsumer into kdelibs/experimental? if it'=
s=20
not too late? that would expose it without BC requirements (although the gu=
y=20
wanting to use it in kdelibs still couldn't, I expect?). I can't remember t=
he=20
exact implications of kdelibs/experimental, but=20
http://techbase.kde.org/Policies/New_KDE_Library_API_Policy seems to imply=
=20
that we just move it in there like moving to kdereview, and the only=20
requirements are to version the library properly and have a cmakelists that=
=20
can build it as its own project.

so, which is better for early adopters, a dbus interface or an experimental=
=20
API? I'm leaning towards experimental, since it'll be less work for them to=
=20
update their patches when the api does become stable.

=2D-=20
Chani
http://chani.ca

--nextPart1818328.Dd1DUgE1a5
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkzJS4IACgkQeGbAwpIS3GxMBQCfd8mOzz4nyborLkbDx+K3wpxt
LT0An0hZesAkJv9eQxHCm2j/1cIiGrJ6
=W6ZX
-----END PGP SIGNATURE-----

--nextPart1818328.Dd1DUgE1a5--

--===============1878414570==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1878414570==--