Problem Description:
A week ago gThumb started giving preference to upper case in my image filenames which means the alpha order does not match that in my Nautilus file manager or in my hard copy lists.
Relevant System Information:
I opened the App Centre and found three instances of gThumb shown:
gThumb Image Viewer, Sergio Schvezov: latest/edge 3.12.7 Install [Tried and it showed 3.12.8 and still used upper case first. Uninstalled but still showed3.12.8 in About]
gThumb, Nils Buchner: latest/stable 3.12.18.2 Open
gThumb Image Viewer, Debian 3:3.12.6-1 Uninstall
When I open gThumb and click on About it shows 3.12.8
What Iāve Tried:
Uninstalled the Buchner and Schvezov versions and gThumb still showed 3.12.8. Now left with no icon in side bar and the Debian version now shows only Uninstall. Used Terminal to open gThumb and pinned the icon to the side bar Now the images are in the correct order, i.e. not case sensitive. But will this Debian version get replaced like it did a few days ago?
Some background information: Last week on my PC gThumb suddenly started giving preference to upper case in my image filenames which meant they were out of order compared with the corresponding list in my file manager. I collect and curate specimens of rocks and minerals and photograph them then give the image a filename consisting of the specimen name, source location and colour etc. Iāve collected thousands of specimens over the last 15 years and therefore have many images and need to be able to show them in the same order as in the file manager. I always use lower case in my filenames but have to use upper case to distinguish names of source locations for the specimens. For example lead is an element but Lead is a city in South Dakota, USA, and therefore needs upper case L.
I have the gthumb version installed from universe (3.12.6) on 24.04 and it sorts by filename with no preference to capitalization. What does the following reveal?
Thanks. At present, in Terminal I get exactly the same response as in your message. My App Centre shows the Debian version as installed and my filename sorting has no preference to capitalization. Iād resorted to the Debian because of the the other two versions in App Centre one gave preference to capitalization and the other couldnāt be installed. However, the following day I found the gThumb had reverted to the 3.12.8 version and capitalization was returned. So once again I installed the Debian version and Iāve got back the `no preferenceā state again. I donāt know why my previous install of the Debian version changed so also donāt know how long it will be before it reverts again.
Iāve just looked in the App Centre and the two non-Debian ones just show a green Install button so Iāve got to hope that an update doesnāt come along and switch me to one of those which is what seemed to have happened in recent days.
I installed the gthumb-unofficial snap (3.12.8 version) and youāre correct that it performs a case-sensitive sort. Which is odd because it seems to be ignoring the locale settings. My locale is set to āen_US.UTF-8ā. AFAIK, LC_COLLATE is the locale variable that programs like Nautilus refer to when determining the file system sort order, and since āen_US.UTF-8ā is supposed be case-insensitive, gthumbās browser should list the files by a case-insensitive sort. So this appears to be a bug unless the developer had a reason for the change. Unfortunately, on gthumbās gitlab page the Changelog is woefully out of date, and the all the changes made to the source is sparsely documented in commit messages.
While a snap might see your environment variables LANG and LC_*, it canāt see your locale files somewhere in /usr/. So unless the snap has the files for your locale included it will probably default to something along the lines of āC.utf8ā.
gthumb-unofficial uses the gnome-46-2404 platform which contains the same locales as 24.04 so it should use them. However, your post gave me an idea
$ LC_COLLATE=en_US.utf8 gthumb-unofficial.gthumb
Now it does case-insensitive sorts! So it may be defaulting to C as you mentioned but itās puzzling since running the locale command in the shell of the gthumb-unofficial.gthumb snap displays the correct values.
Anyway, thanks for helping me stumble on a solution should the OP wish to try the snap version again.
Edit:
Scratch the above about setting environment LC_COLLATE before starting the gthumb snap. It does not work. Apparently in trying different things to get it to see the correct locale, I mistakenly used the deb packaged version and of course it worked as expected.
I investigated further using strace and lsof and found that youāre assumption was indeed correct: it was defaulting back C.utf8 because it couldnāt find the correct locale files.
I got curious and decided to look at the other snap applications and to my surprise none of them are picking up the correct locale settings. They all either default back to C, or they just donāt pick up the locale at all.
Iāve already regenerated the system locales and am in the process of reinstalling the runtimes and checking the connections to see that fixes the issue.