[Digikam-devel] Telepathy KIPI Plugin
caulier.gilles at gmail.com
Tue Mar 6 21:21:08 UTC 2012
2012/3/6 Daniele E. Domenichelli <daniele.domenichelli at gmail.com>:
> At Digikam sprint in Genoa, as you probably remember I started writing a
> kipi plugin for telepathy.
> 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 )
> To build it you will need to build from master ktp-common-internals
> 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...
More information about the Digikam-devel