my sorting ist set to sort by Names ascending and it worked fine until this 7.2.0 beta1 sorting example: 200524_1643_20200524_122754 201024_1556_20201024_155611 201024_1556_20201024_155625 201024_1556_20201024_155638 201024_1556_20201024_155646 200426_140137 200426_140156 as I said it worked before this beta all sortings are a bit strange now - the sorting for album names in the list of albums are different and for tags in the tags list too environment windows 10 64bit German settings digikam 7.2.0-beta 1 with German UI
Go to digiKam setup under miscellaneous and set the string comparison back to its standard value "natural". We have integrated a new fast cache sorter that uses this setting. The new cache sorting is 10 times faster, which brings a significant speed advantage for views with many items. Maik
... as a new user to digiKam (directly started with 7.2.0 beta1) i immediately stumbled upon this bug. (Also verified that it does NOT exist with 7.1 stable) But while i was lucky to find this bug-report it does not seem correct (what is the workaround): For me the setting "natural" does not fix things (and this is/was also the standard - even after all settings/databeses have been cleared/deleted when switching between stable and beta) But when i set it to "normal" things are start work again as expected. What is also weird: when using "list/table" view - it also works with "natural". Environment is the same is the bug-reporter (Win10 64bit - German)
forgot to mention one thing: All pictures in the folders (that show the odd behaviour) have the exact same name-pattern (IMG_YYYYMMDD_hhmmss.jpg - e.g. IMG_20200816_160635.jpg) Therefore i really dont get the difference between those 2 approaches (natural/normal) when reading the explanation from the manual "With the String comparison type setting, you can set the way in which strings are compared inside digiKam. This influences the sorting of the tree views. Natural tries to compare strings in a way that regards some normal conventions. The result will be sort naturally even if they have a different number of digits inside. Normal uses a more technical approach. Use this style if you want to entitle albums with ISO dates (201006 or 20090523) and the albums should be sorted according to these dates."
Git commit f4b91197d9ceb98a265916a76787a3a881662625 by Maik Qualmann. Committed on 11/11/2020 at 07:09. Pushed by mqualmann into branch 'master'. go back to standard QCollator comparison The QCollatorSortKey does not seem to work under Windows. We also see error messages from time to time in the log under Windows. The speed advantage remains because we don't create the QCollator object every time new. FIXED-IN: 7.2.0 M +2 -1 NEWS M +11 -58 core/libs/database/models/itemsortercache.cpp https://invent.kde.org/graphics/digikam/commit/f4b91197d9ceb98a265916a76787a3a881662625
@Maik, it was set to "Natürlich" and I changed it to "Normal" and this is working now. in a german environment "natural" translates into "Natürlich", could it be, that this German Umlaut "ü" does cause some of the problems? Just guessing but as I work for an american software company I know this Umlaut issue ;) Thanks & Cheers Martin
No, the translation has nothing to do with it here. The problem will be fixed in the next beta. The string comparison should be on "Natürlich". I was able to reproduce the problem with the specified file names here in my German Windows 10 VM. As I said, it worked fine on Linux with ICU support, but not on Windows. The desired speed advantage is retained and that is what matters. Maik