[Digikam-devel] Re: libkmap in kdereview

[Michael G. Hansen]

On 03/06/2011 08:51 PM, Marcel Wiesweg wrote:
>
>> I'd agree with a rename, but I'm also slightly concerned the libkgeomap
>> name suggests it is _the_ KDE solution for geomaps and other modules will
>> start using it that way and we will have a de-facto solution without any
>> thought being put into it.  If it's ever intended to be used outside
>> kdegraphics or even eventually moved to kdelibs then a stricter review
>> will be needed, and we'd need to think about how it compares to using
>> QtMobility/QLocation.
>
> We need to wait for Michael's comments here how generic libkmap has become,
> but initially it has been a solution to the problem of having a map from
> different backends and items (photos) grouped on the map, with all usual
> associated features.
 >
> Due to the deeper dependency on marble, which is in kdeedu, a move to
> kdegraphics/libs was already vetoed, because kdegraphics cannot depend on
> kdeedu. I think the current plan is to keep it in extragear (needs to go
> through kdereview as well to be in extragear)

It tried to keep it generic, but find myself modifying it to suit the 
needs of gpssync and digikam in particular. So it's just a collection of 
code which is shared between gpssync and digikam, and which I don't want 
to duplicate.

Therefore, having libkmap in a 6 month kde sc release cycle, which 
differs strongly from the digikam release cycle, would lead us to the 
same situation as with libkexiv2, libkdcraw, etc. Having it in extragear 
would be a good idea IMHO. Maybe it would be even better to keep it 
directly under digikam-sc, to indicate that libkmap is currently 
developed only for digikam/kipi-plugins, kind of like libkoffice is for 
koffice. If another application starts using it, we can rethink that 
decision.

About the name: I don't have any strong opinions on this case, 
suggestions welcome ;-)

Michael