baserev update by copy to link target

• Files Changed
• Browse Source

1.6.0

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- Update to 1.5.0
  * 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.
  * The timezones data files have been updated to Timezone Boundary
    Builder's release 2023d.

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

1.4.0

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- Update to 1.3.1
  * Hotfix: Due to a problem with the tarme.rb releaseme script,
    the 1.3.0 tarball lacked all l10n data. We thus had to withdraw
    the release and tag a new one.
  * New: When using the split images list view and tagging images
    manually, the "assigned" image list now scrolls to the last (or
    only) tagged image and highlights it, so that it's immediately
    accessible for e.g. further corrections.
  * New: Allow setting coordinates directly from the clipboard. As
    of now, Google Maps' format as well as OpenStreetMap's Geo URI
    scheme is supported. (kde#458537)
  * New: It is now possible to open an image with the system's
    default image viewer (for closer inspection), either from the
    image list(s), or from the preview widget.
  * Bugfix: Use "Folder", not "Directory" according to KDE's
    style/vocabulary guidelines. (kde#457020)
  * New: Files and/or directories given on the command line are now
    loaded after startup (which can e.g. also be triggered via
    "Open with" from a file manager like Dolphin).
  * Update: Updated the timezones data files to 2021c.
  * Change: As Marble now has a decent versioning scheme (at least
    since the KDE Apps release 21.12.3), KGeoTag now has a defined
    dependency for Marble: It now depends on at least Marble
    21.12.3. It actually can be built against older versions as
    well, but due to the lack of proper version bumps, there was no
    way to define a definitive version to depend on until now.
  * New/Bugfix: Added a handbook stub. (kde#452534)

• Files Changed
• Browse Source

- Update to 1.2.0
  * Enhancement: KGeoTag now checks if the timezone data files
    could actually be loaded and displays a warning about timezone
    detection not working if not.
  * Bugfix: Made selecting all entries of an image list work again
    via the standard shortcut CTRL+A. This one was assigned to
    "Assign images to GPS data", which can now be  accessed via
    CTRL+M.  (kde#445023)
  * Bugfix: QMimeDatabase::mimeTypeForFile now returns
    application/xml+gpx as a GPX file's MIME type instead of
    application/x-gpx+xml - at least here on my stable Gentoo
    machine. This made KGeoTag refuse to load any GPX file. Now,
    both MIME types are accepted.
  * Change: Suppressed a warning by bumping cmake_minimum_required
    to 3.16.0.

• Files Changed
• Browse Source

initialized devel package after accepting 927557

• Files Changed
• Browse Source

- Update to 1.1.0
  * Bugfix: When walking along a track, the date and time were
    displayed to be in the set timezone, but not actually converted
    to it. Now, the timestamps are translated correctly.
  * Enhancement: Added an "Assign images to GPS data" main menu
    entry. This one triggers an automatic image assignment af all
    loaded images, like "(Re)Assign all images" from the "Automatic
    assignment" dock. The search type to perform can be defined in
    the settings.
  * Bugfix: Enabled exact matching also if a used GPX track and/or
    the image metadata contain milliseconds. If so, the
    `QHash<QDateTime, ...>::contains()` call used to search for
    exact matches won't yield a result, even if there's a
    seconds-exact match (if not also the milliseconds matched, and
    this is quite unlikely).
- Drop 0001-Don-t-look-for-a-specific-Marble-version.patch, merged
  upstream
- Change URL to new project homepage

• Files Changed
• Browse Source

fix build

• Files Changed
• Browse Source

- New application, see https://www.kphotoalbum.org/2021/02/27/0103/

Added %if %{with lang}, I hope I didn't forget one...

• Browse Source