#429 Please sort files case independent

[Rastah Bar]

When attaching a file or disk, the directories listings are sorted first according to capital letters and then follow the lower case letters. For example, "a_disk.d64" comes after "Z_disk.d64". I would prefer it to be listed after "A_disk.d64".

[compyx]

I'm gonna assume you're talking about the Gtk3 port of VICE here.

This is something VICE cannot control since there is no function or property in Gtk3 to use to set the sort order of files in the file dialogs. It depend on the setting of LC_COLLATE
On my system with LC_COLLATE="en_US.UTF-8 the files are sorted case-insensitive, when I run LC_COLLATE=C x64sc, the files are sorted case-sensitive.

So for running x64sc from a shell you could, for example, use this in ~/.bash_profile:

alias x64sc='LC_COLLATE="en_US.UTF-8" x64sc' 

The above of course assumes running the Gtk3 port on Linux (and a bash-compatible shell). If you're using the Gtk3 port on Windows I have no idea, you'd expect the files to be sorted case-insensitive since the filesystem is case-insensitive, but it that doesn't happen. I looked at the properties of x64sc.exe in my Windows 7 VM, but there are no settings for running the program with a different collation or even a locale. I don't even know if Windows has the concept of collation or even setting per-process locale.

So in short: upstream bug we cannot do anything about. I've posted a bug report about this years ago, so I wouldn't count on an upstream fix anytime soon.

[compyx]

Adding to this: please post the VICE version you're using and revision if applicable (in Gtk3 use Help->About) and your operating system (type and version).

[Rastah Bar]

Thanks for your quick response! I'm mostly using Vice 3.5 (GTK3 3.24.23, GLib 2.58.3) on macOs Monterey version 12.0.1. Setting LC_COLLATE doesn't seem to help on mac, but setting environment variables works a little bit different than on Linux, so I will have to try a couple of things.

[compyx]

Alright, let us know if you find out if the behaviour can be changed on MacOS via env vars or other locale settings. It won't properly fix things, but it could at least be a workaround worth mentioning on the Wiki.

[rice123]

On my system with LC_COLLATE="en_US.UTF-8 the files are sorted case-insensitive, when I run LC_COLLATE=C x64sc, the files are sorted case-sensitive.

FWIW:

PS C:\Users\rice> Get-WinSystemLocale

LCID Name DisplayName
---- ---- -----------
1033 en-US English (United States)

And GTK still sorts in this weird case-sensitive way...

I've posted a bug report about this years ago

Do you have a link? I was checking https://gitlab.gnome.org/GNOME/gtk/-/issues and couldnt find it

[gpz]

check https://vice-emu.pokefinder.org/wiki/Upstream_bugs#GtkFileChooser - there is a link

[rice123]

There's a link to https://gitlab.gnome.org/GNOME/gtk/-/issues/900 which is a fixed issue that doesn't affect GTK 3.24.39 which VICE is based on. Thats not related to this problem.

[gpz]

OH. right. @compyx to the rescue :)

[compyx]

There's no way to set the sort method of a GtkFileChooser through the Gtk API, only ascending/descending and "sort directories before files" (which isn't the default but I've enabled since that seems more usual for Windows users), and this needs to be done via gsettings, not methods of a GtkFileChooser.
As mentioned Gtk uses the system locale to collate the files and directories and sort them accordingly (if it didn't you'd have weird results with "Áargh", "Ȧargh", and "Äargh" not being sorted properly).

So the only option would be to set a different locale on the command line while launching VICE, like I did in my first reply. No idea how to do this on Windows though.

[rice123]

The system locale is English (United States) as mentioned above so why does it sort this way? There's no "Áargh", "Ȧargh", and "Äargh" in en-US. What would I gain from setting a different locale and what locale should I choose for it to work properly?

And how's that even relevant to whether the sort is case-sensitive or not? Those weird "A" diacritics have their lower-cased counterparts too so there'd still be two ways to sort them. Gtk would have to be seriously broken to work this way. Can you post a link to the bug?

[compyx]

What bug would that be?

[rice123]

Oh and one more thing: I installed GIMP 2.99.18 which is the other program using GTK3 on Windows and sorting is case-insensitive there when File->Open is used. I don't think it gets a different locale.

[compyx]

GIMP still uses Gtk 2, and iirc maintains a set of patches to fix issues with Gtk, we use Gtk 3 and don't have the resources to patch upstream libs to our liking, or that of users.

[rice123]

GIMP still uses Gtk 2

No, GIMP 2.99 is a preview of GIMP 3 which uses a GTK3-based user interface.

[compyx]

I just checked the source of their UI code, it appears they've created their own custom widgets and dialogs using Gtk3, so it's even worse than maintaining a set of patches.

Of course for something as domain-specific as GIMP it might make sense to do this, it doesn't for us. We're stuck with Gtk3 and whatever weird design decisions the Gnome/Gtk make, which usually unfortunately involves dumbing down the API and making it more and more Gnome desktop-specific.

So there really is nothing we can do about the sort order of the dialogs, as I mentioned before.

[rice123]

So there really is nothing we can do about the sort order of the dialogs, as I mentioned before.

This is clearly incorrect. The cause of the problem (apart from GTK being GTK) is that you're destroying the LANG env variable in /src/arch/gtk3/gtk3main.c:

    /*

     * Ugly hack to make the VTE-based monitor behave on 32-bit Windows.
     *
     * Without this, the monitor outputs all sorts of non-ASCII glyphs resulting
     * in either weird tokens and a red background or a nice crash.
     *
     * The Windows C runtime doesn't actually use this env var, but Gtk/GLib
     * does. Ofcourse properly fixing the monitor code would be better, but I've
     * spent all day trying to figure this out, so it'll have to do for now.
     *
     * --Compyx
     */
#ifdef WINDOWS_COMPILE
    _putenv("LANG=C");
#endif

GTK depends on it to select the locale so no wonder things fail to work properly in Windows builds. I've managed to bypass this bogus putenv() call in windbg and I can confirm that sorting works correctly without it.

[rice123]

To add more context: the LANG env variable is not defined on Windows by default. However if it's set, it takes precedence over the system settings due to how GTK performs locale lookups. That's why no amount of locale changes would change the behavior - GTK would always use "C" on Windows and behave as described here:

when I run LC_COLLATE=C x64sc, the files are sorted case-sensitive.

[compyx]

Interesting, I don't even remember adding that hack. Guess we'll see how the monitor behaves once we remove that hack.

[compyx]

I've removed the hack, looks like sorting case-insensitive does work now on Windows 11 (locale is Dutch, but the language is en-US) and also appears to have effect on my Debian box.
I haven't seen any ill effects with the VTE-based monitor on Windows, so perhaps this hack is no longer required, or perhaps just needed for 32-bit Windows builds, which we don't provide anymore anyway.

Thanks for noticing that pesky hack =)