Menu

#110 "sort files and directories by" option

SVN
open
nobody
None
5
2025-12-02
2018-04-23
chrm
No

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.

Related

Bugs: #110

Discussion

  • chrm

    chrm - 2019-07-07

    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
    • Spencer Berger

      Spencer Berger - 2019-07-15

      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.

      LANG=en_US.UTF-8
      LC_CTYPE="en_US.UTF-8"
      LC_NUMERIC="en_US.UTF-8"
      LC_TIME="en_US.UTF-8"
      LC_COLLATE="en_US.UTF-8"
      LC_MONETARY="en_US.UTF-8"
      LC_MESSAGES="en_US.UTF-8"
      LC_ALL=
      

      What order is shown with the command 'LC_ALL=C ls' ?

       

      Last edit: Spencer Berger 2019-07-15
  • chrm

    chrm - 2019-07-16

    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.

    chrm@chrm-desktop:~$ locale
    LANG=en_US.UTF-8
    LANGUAGE=
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC=de_DE.UTF-8
    LC_TIME=de_DE.UTF-8
    LC_COLLATE="en_US.UTF-8"
    LC_MONETARY=de_DE.UTF-8
    LC_MESSAGES="en_US.UTF-8"
    LC_PAPER=de_DE.UTF-8
    LC_NAME=de_DE.UTF-8
    LC_ADDRESS=de_DE.UTF-8
    LC_TELEPHONE=de_DE.UTF-8
    LC_MEASUREMENT=de_DE.UTF-8
    LC_IDENTIFICATION=de_DE.UTF-8
    LC_ALL=
    
    chrm@chrm-desktop:~/test$ /bin/ls
    '(a.zip'  '[a.zip'  '(b.zip'  '[b.zip'
    
    chrm@chrm-desktop:~/test$ LC_ALL=C /bin/ls
    '(a.zip'  '(b.zip'  '[a.zip'  '[b.zip'
    
     
    • Spencer Berger

      Spencer Berger - 2019-07-17

      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.

       
    • Spencer Berger

      Spencer Berger - 2019-07-17

      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:

      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.

      chrm@chrm-desktop:~$ locale
      LANG=en_US.UTF-8
      LANGUAGE=
      LC_CTYPE="en_US.UTF-8"
      LC_NUMERIC=de_DE.UTF-8
      LC_TIME=de_DE.UTF-8
      LC_COLLATE="en_US.UTF-8"
      LC_MONETARY=de_DE.UTF-8
      LC_MESSAGES="en_US.UTF-8"
      LC_PAPER=de_DE.UTF-8
      LC_NAME=de_DE.UTF-8
      LC_ADDRESS=de_DE.UTF-8
      LC_TELEPHONE=de_DE.UTF-8
      LC_MEASUREMENT=de_DE.UTF-8
      LC_IDENTIFICATION=de_DE.UTF-8
      LC_ALL=

      chrm@chrm-desktop:~/test$ /bin/ls
      '(a.zip' '[a.zip' '(b.zip' '[b.zip'

      chrm@chrm-desktop:~/test$ LC_ALL=C /bin/ls
      '(a.zip' '(b.zip' '[a.zip' '[b.zip'


      [bugs:#110] https://sourceforge.net/p/mcomix/bugs/110/ "sort files
      and directories by" option

      Status: open
      Group: SVN
      Created: Mon Apr 23, 2018 06:49 PM UTC by chrm
      Last Updated: Mon Jul 15, 2019 05:04 AM UTC
      Owner: nobody

      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.


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/mcomix/bugs/110/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #110

  • chrm

    chrm - 2019-07-20

    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.

     
  • bandapple59

    bandapple59 - 2025-12-02

    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

Log in to post a comment.