I’m delighted to announce the new major release of KGeoTag, the stand-alone KDE/Linux geotagging app: Version 2.0.0. Right on Friday the 13th ;-) The major version has been bumped because finally, the support for Qt 5 has been removed.
A few other changes also happened, mostly inspired by Bug #514067:
Added Marble's search functionality to search for places and retrieve their coordinates.
The map's current center can now be shown on OpenStreetMap or Google Maps (via URL and web browser). This can be requested by the context menu: Either directly on the map via "Current map center" and "Open with ...", or the "Open with ..." entry of the context menu for the map center display below the map.
Apart from this, the timezones data files have been updated to Timezone Boundary Builder's Release 2026a.
Currently, KGeoTag can be built against Qt 5 and Qt 6. My initial plan was to support Qt 5 as long as it wouldn’t hurt too much, to stay compatible with older LTS distros. Recently, I got a message about libkexiv2 dropping Qt 5 support. Being a core part of KGeoTag, this would prevent further Qt 5 support for KGeoTag.
However, I then checked the current state, and it seems that the Qt 5 air is thinner as I thought it was meanwhile: Meanwhile, the Qt 5 version of Marble has been removed from Gentoo’s repositories. So, no matter what libkexiv2 does, I can’t build KGeoTag against Qt 5 anymore on my own desktop machine. And I won’t mess around with some VM or whatever to do so.
Well, seems like the Qt 5 times are actually finally over, and faster as I thought they would be. Consequently, I’ll remove Qt 5 support from KGeoTag as well. It was a nice time, I really liked you – but now: farewell, Qt 5!
I’m happy to announce the new 1.8.0 release of KGeoTag, the stand-alone KDE/Linux geotagging app!
There have been a few changes regarding handling coordinates, mostly inspired by Bug #497410. We now can:
Assign an image to coordinates from the clipboard which are (partly) negative (which fixes said bug)
Export the current map center’s coordinates in the decimal degree “latitude, longitude” format to be used e.g. in Google Maps or OpenStreetMap
Not only assign coordinates from the clipboard that have been copied from OpenStreetMap or Google Maps, but also using the human-readable format that KGeoTag itself formats when selecting “Copy formatted coordinates” for the current map center (provided the coordinates string has been formatted using the same locale as is used to parse it)
I’m happy to announce the new 1.7.0 release of KGeoTag, the stand-alone KDE/Linux geotagging app!
No functionality has been changed/added/etc., there’s only one change: KGeoTag can now be compiled against Qt6/KF6. Decently, it was possible to keep the codebase compatible with Qt5/KF5 as well, so that distros not having bumped to Qt 6 still can ship new versions of KGeoTag. I’ll try to keep the Qt 5 compatibility as long as possible, the goal is until Ubuntu LTS is Qt 6 based. Let’s see though if this will actually work out.
At the moment, you probably can’t build KGeoTag 1.7.0 with what your distro ships, because there’s a chicken-and-egg problem with a core dependency, Marble: As of now, there’s no Qt6/KF6 release of Marble. But one will be tagged in a few days. The problem is that you can’t upgrade Marble as long as you have KGeoTag <1.7.0, because it depends on the Qt 5 version of Marble. But you can’t build the Qt 6 KGeoTag if you don’t upgrade Marble.
The solution is this release: Distributors can now package both the new Marble and KGeoTag versions and upgrade both simultaneously.
A note to the packagers: KGeoTag will use Qt5/KF5 if it finds it. In a Qt-6-only environment, it will compile against Qt 6. If you have both Qt 5 and Qt 6 installed, a Qt6/KF6 build can be forced using ECM’s BUILD_WITH_QT6 switch, i.e. by passing -DBUILD_WITH_QT6=ON to cmake.
Have a lot of fun with the new version of KGeoTag :-)