[Digikam-devel] Telepathy KIPI Plugin

[Gilles Caulier]

Hi Daniele,

2012/3/6 Daniele E. Domenichelli <daniele.domenichelli at gmail.com>:
> Hello,
>
> At Digikam sprint in Genoa, as you probably remember I started writing a
> kipi plugin for telepathy.

sure..

> I had to fix a few things in our kde-telepathy internal library before being
> able to show you some code that you can "easily" build...
>
> The code is in the "telepathy" branch in my kipi-plugin clone
> (kde:clones/kipi-plugins/ddomenichelli/kipi-plugins.git [1])
>
> To build it you will need to build from master ktp-common-internals[2]
>
> Now, there is a big problem in merging this into kipi-plugins: this library
> is quite unstable, it's an internal library that we are using for shared
> stuff, but at the moment we cannot guarantee any api/abi stability. To avoid
> people linking against it we have a flag IS_KTP_INTERNAL_MODULE that the
> FindKTp.cmake checks, and if it is not set it does not "find" the library
> (it's not the best way to do it, but for now it is good enough for us)
>
> At the same time I cannot release outside of the kipi-plugins, because it
> uses some classes of the kipi-plugins internal library
> (KIPIPlugins::KPImagesList and KIPIPlugins::KPAboutData)
>

you can make a copy of libkipiplugins code in the external plugin
version. It's not the best solution, but it can be a temp way...

> What do you suggest to do?

What's the plan to render ktp-common-internals API stable ?

If this ktp-common-internals library is not to huge, why not to
temporally integrate as 3rd party in plugin as well ?

Of course, until API becaome stable, shared and 3rd party code need to
be synchronized. This prevent to add an unstable external dependency
from a period where API must be stabilized...

Best

Gilles