My filemanager shows files in this order '(a.zip' '[a.zip' '(b.zip' '[b.zip'
With the option "Automatically open the next archive" activated Comix shows them in this order '(a.zip' '(b.zip' '[a.zip' '[b.zip'
The option "sort files and directories by" doesn't allow me to select the same order.
It's still happening. To give some more context, it's very disorienting when the sorting order is not the same as in the filemanager. Imagine you open the first archive in a directory from the filemanager and then go through all the archives with 'next-archive'. You will not necessarily see all archives.
I'm on Linux and 'ls' and probably all other filemanager use that order. You are probably on Windows and that uses the other order?
Last edit: chrm 2019-07-07
The order your system uses doesn't make much sense. If it was just your filemanager I would say that your filemanager uses a natural order different than mcomix, but if ls uses it it must be the locale. Can you post the output of the 'locale' command? It should be something like.
What order is shown with the command 'LC_ALL=C ls' ?
Last edit: Spencer Berger 2019-07-15
I guess this means mcomix doesn't consider my locale for sorting. I have a fresh installation of Ubuntu and my locale is a mix of German and English.
Tried to reply to the email to post this (didn't seem to work or result in an error message), so hopefully it doesn't double post.
It turns out I do see this behavior in Debian even with an en_US.UTF-8 locale, it's probably a glibc thing. The hover text on the archive sort setting mentions that "literal order uses standard C sorting," so I think this is the intended behavior for mcomix. Attached is a patch that adds a locale sorting option, try and see if that works.
It turns out I do see this behavior in Debian with a en_US.UTF-8 locale,
it's probably a glibc thing. The hover text on the archive sort setting
mentions that "literal order uses standard C sorting," so I think this
is the intended behavior for mcomix. Attached is a patch that adds a
locale sorting option, check and see if it works.
On 7/16/2019 4:40 AM, chrm wrote:
Related
Bugs: #110
Thanks for looking into it. I tried it and this patch works for the sorting of images inside an archive. Unfortunately my problem was the sorting of archives inside a directory.
This has been bothering me too for a long time and I finally spent some time on it.
The sort order GTK file managers and some other GTK applications are using isn't just decided by the locale (though it's one factor) but by the function GLib.utf8_collate_key_for_filename. I created a fork/branch under https://sourceforge.net/u/bandapple59/mcomix/ci/sort/tree/ which allows choosing that sort order both for files/directories as well as archives.
The resulting sort order doesn't necessarily exactly match the file manager as the file manager may apply custom logic on top of GLib.utf8_collate_key_for_filename. E. g. Nautilus, Nemo and Caja will sort files beginning with # at the very end, while Thunar and PCManFM make sorting "more case-insensitive" (i. e. they will sort image1.jpg Image2.jpg image3.jpg; GLib.utf8_collate_key_for_filename with locale set to en_US.UTF-8 causes these files to sort as image1.jpg image3.jpg Image2.jpg because with otherwise identical alphabetical strings it will always sort lowercase before uppercase). As this additional logic isn't consistent across file managers/applications though, I'd say it's probably best to stick to just GLib.utf8_collate_key_for_filename.
Attached is a diff of the changes I made.
Last edit: bandapple59 2025-12-02