Telepathy KIPI Plugin

[Daniele E. Domenichelli]

Hello,

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 [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)

What do you suggest to do?

Cheers,
  Daniele


[1]http://quickgit.kde.org/index.php?p=clones%2Fkipi-plugins%2Fddomenichelli%2Fkipi-plugins.git&a=shortlog&h=refs/heads/telepathy
[2]https://projects.kde.org/projects/extragear/network/telepathy/ktp-common-internals
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Hi Daniele,

2012/3/6 Daniele E. Domenichelli <[hidden email]>:
> 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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Daniele E. Domenichelli]

On 06/03/12 22:21, Gilles Caulier wrote:
>> 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...

I think I will adopt this solution for now, I don't like it because it
won't be easy to follow the changes from libkipiplugins, but it's the
option that will break less stuff in the future...


>>  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...

We don't have a real plan about stabilization of the
ktp-common-internals library yet, we have still a lot of things missing
and we don't know yet what we will break implementing those things
(first of all, meta-contacts support is likely to break almost everything)

What about libkipiplugins? Are you planning to consider it "stable" and
install the headers one day?


Cheers,
  Daniele
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2012/3/6 Daniele E. Domenichelli <[hidden email]>:

> On 06/03/12 22:21, Gilles Caulier wrote:
>>>
>>> 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...
>
>
> I think I will adopt this solution for now, I don't like it because it won't
> be easy to follow the changes from libkipiplugins, but it's the option that
> will break less stuff in the future...

As i manage with students this part, i can notify you about important changes.

>
>
>
>>>  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...
>
>
> We don't have a real plan about stabilization of the ktp-common-internals
> library yet, we have still a lot of things missing and we don't know yet
> what we will break implementing those things (first of all, meta-contacts
> support is likely to break almost everything)
>
> What about libkipiplugins? Are you planning to consider it "stable" and
> install the headers one day?

I polished a lots this library to be ready for GSoC 2012. No important
changes will be done for few month i think.

We will never share this lib. It's an internal component for plugins.
digiKam team already manage a lots of shared libs (too much for me...)
and must take a care about BC. It's a complex puzzle.

The goal for you is to integrate officially your plugin in
kipi-plugins in the future. This is the real solution. I recommend to
be focused to stabilize API/ABI of your shared telepathy lib.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel