Do we need a KF5-based version of libkgeomap?

[Alexander Potashev]

Hi Tobias,

Gilles has recently made the decision that libkgeomap code is imported
into the KF5 version of digiKam core, in order to minimize the number
of libraries digiKam team needs to maintain.

In the KDE4 world libkgeomap is used by digikam, kipi-plugins (the
"geolocator" plugin) and kphotoalbum. The geolocator tool was moved
from kipi-plugins into digiKam-5.x core (only for the KF5-based
version), so for now libkgeomap is only used by digiKam internally and
the source code is simply incorporated in the digikam Git repo.

Question is, will KF5-based libkgeomap be used soon by other projects?
If yes, then we will finally have to make a release (libkgeomap-5.0?).
And then we end up with two copies of the same codebase: one in
libkgeomap.git and another in digikam.git (which is already slightly
modified because it is not a shared library there anymore). It should
be clear to everyone that two forks of the same code are hardly
maintainable.


All in all,
 - Are you going to port KPhotoAlbum to KF5?
 - What should we better do with libkgeomap at the moment and when
should it be released, in your opinion?
 - Can you maintain libkgeomap/KF5 as a shared library? (This means
patch reviews, ABI maintenance, bug fixing/triaging, etc.)

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

[Tobias Leupold]

Hi :-)

>  - Are you going to port KPhotoAlbum to KF5?

I think there will definitely be a KF5 port of KPA eventually. At the moment,
no such action is going on, but I think when at least a few of the "core"
developers of KPA begin to use KF5, we will start to port it. It's not such a
big project after all, we're just a few active developers ... speaking of me,
Gentoo's stable default KDE is still 4.x, but as soon as Gentoo switches to
KF5, I would like to have KPA based on Qt5/KF5. I'll definitely work on that
"when it's time".

>  - What should we better do with libkgeomap at the moment and when
> should it be released, in your opinion?

From my point of view, the current libkgeomap is just fine, so I think KPA is
quite happy with the current state of the code. As long as there are no
critical bugs, I think we can keep on using this code. And, as said, there
will be surely a KF5 port, and then, we would like to use a new libkgeomap
version of course. But – always only speaking of me of course – I think
there's no haze at the moment.

>  - Can you maintain libkgeomap/KF5 as a shared library? (This means
> patch reviews, ABI maintenance, bug fixing/triaging, etc.)

I personally definitely can't :-( I'm quite happy I was able to kind of use
it. It's a quite complicated library for me as C++/Qt n00b, the "deep" things
that had to be done have been implemented by Johannes Zierl-Zarl.

After all, the right way would be imho that libkgeomap would be maintained as
a shared library without a Digikam included codebase (I really don't
understand that packaging thing in Digikam – either it's an independent
library or it isn't, why is some library code even packaged with Digikam in
the first place?!). It was quite an effort for me to convince the KDE folks
that libkface should be an own KDE project (cf. the move a few months ago). I
failed to do so with libkgeomap (but I really tried). I think Digikam should
depend on a shared libkgeomap, as everybody else could and it definitely
should be a shared library. If it had not been, we from KPA would have never
used it.

All in all, I think I can state that we from KPA definitely would like to
still use libkgeomap when we start to port it to KF5. So it would be nice if
it kept on being a "normal" shared library.

Cheers, Tobias

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