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 :-)
I'm happy to announce the new release of KGeoTag, the KDE/Linux Photo Geotagging Program! There are a few changes and updates:
Coordinates format is now configurable
When I wrote KGeoTag back then, I spared not a single thought on how to order or format geographic coordinates. I thought one would do that like in a cartesian coordinate system: First X, then Y. So: First the “X-ish” longitude, then the “Y-ish” latitude. One never stops to learn: It actually seems to be common practise to first put the latitude, and the longitude afterwards. But it seems like there’s no real “official convention” or “best practise” about this.
Long story short: Everyone can now choose their preferred “coordinates flavor”. One can either select “Latitude Longitude” or “Longitude Latitude”. On top of that, one now can also select how the respective coordinates should be displayed: As decimal degrees (like 50.321373° N), degrees and decimal minutes (like 50° 19,2824' N) or degrees, minutes and decimal seconds (like 50° 19' 16,94" N). All “coordinate flavors” display a reasonable amount of decimal places so that the precision is better than 1 m at the equator. However, the cardinal directions are always added, so that it’s always clear what’s going on.
Additionally, coordinates can now be copied to the clipboard, either using the map’s context menu or the coordinates display below the map. The context menu can now also be used to add bookmarks.
Other changes
It’s now possible to (re-)assign all currently selected images to the current map center using a keyboard shortcut. Optionally, you can also have the next untagged image selected automatically afterwards. Thanks to Robert Menger for the respective feature request :-)
Updated the timezones data files to 2024b (cf. Timezone Boundary Builder’s Release Announcement).
Fixed a crash when removing a GPX track and moving the “track walker” slider afterwards. Whilst doing so, also fixed the track points counting for slider when removing a GPX track and loading another one directly afterwards.
Changes to the image list layout (combined/separate) are now displayed correctly (again).
The window state saved by the KXmlGuiWindow/KMainWindow class is now used to restore the dock arrangement (or setup the default one) instead of saving the saveState() twice, only using a different serialization. Also, the last window position is now restored correctly when closing the program and opening it again.
Closed floating docks are now properly restored by using “Set default dock arrangement”. This addresses bug #488597, but actually, it’s an upstream Qt bug (reported as bug #126418), as the docks shouldn’t be closable at all in the first place.
A note to the distributors
It should now be possible (again) to build KGeoTag on Ubuntu LTS 20.04 (the latest still-supported LTS version).
The key used for signing the release has been updated. All PGP keys used to sign KDE software releases can be found in the sysadmin/release-keyring repo. My currently used key can also be found there, cf. tleupold@key2.asc.
… and what about Qt 6?!
This is another Qt5/KF5 release. The reason is quite simple: Marble, the backend that is used to display the map, has not yet been ported to Qt6/KF6.
I wrote about this to the KDE Dev Mailing List. Fortuantely, this seemed to have set some action in motion (or maybe my recent in-person nagging at Akademy Würzburg?! ;-). At least, there’s currently a (not released yet) buildable and working Qt 6 branch of Marble.
As soon as there’s an official Qt6/KF6 release of Marble, porting KGeoTag should be a no-brainer. And I’m pretty sure it will also be possible to support both Qt 5 and 6 for the forseeable future. So as soon as Qt 6 Marble is out, I’ll strive to do a Qt 6 KGeoTag release as fast as possible.
Have a lot of fun geotagging your photos with the new release of KGeoTag :-)
Almost one year passed since the last release of KGeoTag, the KDE/Linux standalone geotagging program. Which doesn't mean that the development stalled, quite the opposite :-) It seems like the feature set KGeoTag now has is slowly but surely suitable to do it's one job: To geotag photos in a convenient, graphical way.
However, there are two alterations, and thus, it's time to finally make a new release:
It's now possible to find the chronologically closest track point for an unassigned image and center the map there. If an image has been taken in the time between two tracks, one can find the last or first coordinates of the track recorded before or afterwards (whichever is closer) and use them as a basis for manual tagging.
I'm pleased to anncounce the new 1.4.0 release of KGeoTag, the stand-alone geotagging program!
The most "visible" change of this release is: KGeoTag now supports handling of some TIFF-based RAW image formats (cr2, nef and dng). By default, XMP sidecar files are created for those (regardless of the global setting). Additionally, there's a new option for enabling direct Exif header changes for RAW files.
Thanks a lot to Angel Lopez to bring this up and help to implement this properly!
Additionally, some minimum depencency version bumps have been done (KF 5.68.0 and Qt 5.12.0). Those should be fine with older (LTS) distributions. The dependency bump to Marble 21.12.0 broke the compatibility with (at least) Ubuntu LTS 20.04 and Debian Bullseye. As KGeoTag could always be compiled against Marble from the beginning, the required Marble version is now omitted again, until >= 21.12.0 hits LTS distros (the first Marble version to have decent versioning).
TL;DR: KGeoTag can now be built (again) on Ubuntu LTS 20.04 and Debian Bullseye – without any manual changes.
Last but not least, the timezones data files have been updated to the 2022g release of Timezone Boundary Builder. Due to some changes to the script creating the timezones map KGeoTag uses from it, we now 1. have much less changes to the timezones.json file on changes to the underlying data and 2. much nicer colors in timezones.png ;-)