libkmap in kdereview

[Christoph Feck]

Hi,

I have not seen a new announcement yet, but I assume the kface and kmap
libraries are in review currently.

As I already stated, I suggest to rename "libkmap" to maybe "libkgeomap". The
word "map" in programming context is mostly understood in the "data mapping"
sense, and renaming would avoid possible confusion.

Christoph Feck (kdepepo)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Yes,. I announced these libray few month ago to be reviewed in kdereview.

The way to host these libraries at the right place in KDE project is
not yet decided. The subject still open.

For libkmap => libkgeomap, I let's Michael G. Hansen to choose...

Gilles Caulier

2011/3/6 Christoph Feck <[hidden email]>:

> Hi,
>
> I have not seen a new announcement yet, but I assume the kface and kmap
> libraries are in review currently.
>
> As I already stated, I suggest to rename "libkmap" to maybe "libkgeomap". The
> word "map" in programming context is mostly understood in the "data mapping"
> sense, and renaming would avoid possible confusion.
>
> Christoph Feck (kdepepo)
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

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

On Sunday 06 March 2011 12:30:46 Christoph Feck wrote:

> Hi,
>
> I have not seen a new announcement yet, but I assume the kface and kmap
> libraries are in review currently.
>
> As I already stated, I suggest to rename "libkmap" to maybe "libkgeomap".
> The word "map" in programming context is mostly understood in the "data
> mapping" sense, and renaming would avoid possible confusion.
>
> Christoph Feck (kdepepo)

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.

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

[Marcel Wiesweg]

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

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

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