Sort by file name broken
GIMP (GNU Image Manipulation Program) is a free image editor
Brought to you by:
lisanet
Menu
▾
▴
#16 Sort by file name broken
closed-fixed
nobody
None
5
2014-08-20
2009-11-15
Anonymous
No
In the open-file dialog box (maybe others, I haven't actually checked yet) sorting by name doesn't work correctly. I get the filenames out of order.
Running Snow Leopard 10.6.2 on a Mac Pro, 32-bit kernel, GIMP is running in 64-bit mode.
not reproduced with Gimp 2.6.7p3 on Leopard 10.5.8, Xquartz 2.4.0, LANG "en_US"
- Folders and files in the 'Open…' dialog are sorted correctly by 'Name', by 'Size' or by 'Modified', per default alphabetically by name.
- The number of files in a directory or the used file type filter doesn't make a difference.
- As in the Finder lower/upper case is ignored: the list of files sorted by names looks different than the output of '/bin/ls -1'. The GtkFileChooser used with current Inkscape.app SVN builds (gtk2 @2.16.4_0+x11) shows the same behavior as the current Gimp.app whereas older GtkFileChooser versions (e.g. those bundled in Inkscape 0.46 from early 2008) used the same sorting order as the default '/bin/ls' command: upper case first, lower case after all upper case.
oohh, that's really weird!!
My system:
Mac OS X: 10.6.2
X11: 2.3.4
running GIMP 2.6.7p3 for Leopard:
files are in alphabetical order. Everything fine, just like suv-sj has reported.
running GIMP 2.6.7p1 for SnowLeopard
files are somehow sorted by length -> alphabetical -> lower case -> upper case -> ???
Weird.
Both versions have been built using identical sources. (take a look at Contents/Resources/gimp-build.txt)
Same problem here with Gimp 2.6.7p1 for Snow Leopard.
My system: Mac Pro running 10.6.2, everything in 64-bit
XQuartz: 2.3.4 (installed with Snow Leopard)
My system: MacBookPro 2G, 10.6.2. Just installed 2.6.8. Retried from 2 mirrors, just to be sure. Open dialog sorts correctly by date when requested.
Name sort has no pattern that I can detect except that, when "Name" is clicked a second time, the "order" (as Gimp calls it) is correctly reversed.
Again: names are not listed by length (number of characters), extension, upper/lower case, combination with date (or any portion of date, spelled or numeric) or lack thereof. Those few names that are in alpha order are, as might be expected in a list of greater than 26 names, purely at random.
Still present on Gimp 2.6.8 on Mac OS 10.6.2, XQuartz 2.3.4.
just to clear something up:
this bug is on every Snow Leopard version. Leopard and Tiger versions are not affected. As far as I can tell up to now, it's not related to GIMP but somehow more to Snow Leopard itself and some system routines which will give back the files.
Currently I have no solution for that.... sorry.
Are there any developers out there who are familiar with GTK+ and GLIB on Mac OS X?
To be even more clear, this bug only shows when you run Gimp for Snow Leopard on a Snow Leopard machine. If you run the Leopard version of Gimp on Snow Leopard you do *not* have the bug. Therefore it looks definitely something related with the GTK+/GLIB runtimes on SL rather than the operating system itself.
Both versions, Leopard 2.6.7 and SL 2.6.7, were build using identical sources. I didn't touch GTK+ / GLIB / GIMP sources, when I compiled them for SL. The only differences are, that the Leopard version was build on a Leopard system and the SL verson was build on a SL system. The Leopard version is a universal binary running on ppc and i386, the SL version is Intel only running on x86_64 and i386 systems.
... forgot to mention.
SL 2.6.8 still uses identical GTK+ / GLIB sources as on Leopard 2.6.7 / SL 2.6.7. So, as I wrote: only Sl version have this bug. not Leopard or Tiger version (regardless on waht system you run these, and of course, only Leopard version can be run on two OS X versions, namely Leopard and SL)
So I still think it's related to the OS. There might be something linked in (statically ?) on SL which causes this misbehaviour.
Simpleton comment/question for @lisanet: this doesn't appear to occur with any other SL app. I'm not in the habit of rebuilding/compiling apps. Aside from dragging/dropping pix from "intelligibly ordered" Finder display: your proposed solution?
which apps do you mean? Are those apps GTK+ apps built on SL as 64 bit / 32 bit binaries?
@ ~suv: Do you know how the current Inkscape has been built? Does it show this behaviour?
And sadly: either use "File -> Open" or drag & drop from a Finder window.
Maybe I'll try to update GTK+ to 2.18 hoping this would magically solve the problem... (but this may take some time because there are so many other things to do...)
> Do you know how the current Inkscape has been built?
There's only one recent official release build of Inkscape 0.47 that runs on both Leopard and Snow Leopard. (see this thread on inksccape-devel: <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/32156/focus=32162>)
I don't have the 'port installed' list available that Michael used for the final release version, but since inkscape uses MacPorts as is, I assume he used an updated tree from around 2009-11-24. I can look up the available versions if needed.
As far as I know there have been no (known) builds in 64bit on Snow Leopard (only requests ;), nor have there been reports that this alpha-sorting issue occurs with the Inkscape 0.47 Leopard build running on Snow Leopard.
A search in bugzilla.gnome.org for GtkFileChosser didn't get any related hits.
Can't someone on SL run GIMP through gdb, trying to step through the file-opening procedure to maybe get an idea what is going on when alpha-sorting the file list?
You can use gdb very easily by changing one line in one of the launcher scripts:
1) in 'Contents/Resources/bin/gimp', temporarily replace line 11 with
/usr/bin/gdb gimp-2.6 "$@"
2) launch gimp from the command line with
$ /tmp/skl/Gimp.app/Contents/Resources/script
3) after loading the shared libs, you get the gdb prompt. Now you can use 'run' to execute gimp-2.6. Beyond that I can only refer to 'man gdb' ;(
~suv
ps. what about other GTK+ apps ported to OS X 10.6 Snow Leopard? (I don't know if Wireshark, Pidgin, SciTE, vim +gtk2, ... build on SL as universal binaries)
> There's only one recent official release build of Inkscape 0.47
... and that has been built on Leopard as Universial PPC, i386 - afaiu:
$ file inkscape-bin
inkscape-bin: Mach-O universal binary with 2 architectures
inkscape-bin (for architecture ppc7400): Mach-O executable ppc
inkscape-bin (for architecture i386): Mach-O executable i386
~suv
lisanet wrote:
> Maybe I'll try to update GTK+ to 2.18 hoping this would
> magically solve the problem...
Additionally it might be worthwhile to patch an updated version of 'muniversal-1.0.tcl' to ignore the *.py|c|o file diffs when merging - the one in gimponosx r98 is based on MacPorts r54754 (# $Id: muniversal-1.0.tcl 54754 2009-08-01 19:26:04 …), the file in trunk has seen several changes since August.
You haven't seen any related tickets or mails in macports-users describing similar issues with alpha-sorting in GTK+ apps on SL?
Has anyone built Dia on SL?
Another idea: gtk2 installs a small test application called 'gtk-demo'. Anyone who has a MacPorts installation on Snow Leopard (with gtk2 installed) should be able to launch it from the terminal and for example call the GtkFileChooser dialog from the demo widget 'Pickers' (click on the folder icon for 'File:' in the 'Picker' window). Does this dialog have the same error for sorting by file name when using a different MacPorts installation on another computer or with a different osx (e.g. clean install vs. migration) or file-system (e.g. case-sensitive) configuration?
~suv
suv-sf wrote:
> Additionally it might be worthwhile to patch an updated version of 'muniversal-1.0.tcl'
hhmm, I've diffed this version to mine. Besides some fixes of typos, the changes seem minor and AFAICS, they shouldn't affect GTK+ / GLIB
But, I'm currently working on pathcing the color picker and wrote some code, which uses a 'guchar *' pointer to a pixbuf data and some pointer arithmetic on that pointer to get the correct pixel. Something really weird occured. While the code runs well on SL (it picks up the correct pixel and color) it segfaults on Leopard. The segfault occurs when I access each color channel by doing a 'red = pixel[0]', which should work well on an array of 'guchar *pixel'.
I'm totally stunned, since guchar is '#typedef unsigned char guchar', which shouldn't make any difference on any platform I know. Or is 'char' defined differently in Leopard and SL? Something like 8 bit to 16 bit, like ASCII (8 bit) to UTF-8 (16 bit). Is this related to the sort order of files, because of different encodign of guchar, ASCII vs. UTF-8 ?
... sorry, I meant UTF-16 not UTF-8.
From what I've found on the net, Mac OS X should use UTF-16 internaly. That means a 'char' could be 16 bit. Now, if that was somehow changed on SL to char being 8 bit (UTF-8 ?) that could lead to this weird discrepancy between SL and Leopard. On Leopard (16 bit char) file names encoded in UFT-8/UTF-16 would be shown correctly by GLIB/GTK, while my pointer arithmetic - which implies that guchar is 8 bit - will fail. OTH, on SL GLIB/GTK will have guchar as 8 bit, which will fail on file names, but the pointer arithmetic will work... If that's the cause of these two bugs, than another problem occurs. How can I fix this?
I'm investigating further.
arrgh, forget about my previous posting.
The segfault was caused by an error in accessing an already freed data. Still, what makes me wonder, is why only the Leopard build segfaults in the first place and SL didn't, although the sources are identical.
Now IMO it's time to release new builds for SL and Leopard containing the bug fixes for screenshot, color picker, a modified plugin for scanner access and, once again, some other dot files and dot directories.
Nevertheless, the issue about the sort order of file names may still be somehow related to different usage of encodings...
> hhmm, I've diffed this version to mine. Besides some fixes of typos, the
> changes seem minor and AFAICS, they shouldn't affect GTK+ / GLIB
You are right - sorry, my comment was off-topic here. I just had noticed the different rev. numbers when I updated your scripts from SVN and out of curiosity wanted to know more about that patch (since I could not find a related ticket in the MacPorts bug tracker). The connection was 'update GTK+ to 2.18' (my thinking: you'd have to re-apply the patch if you update MacPorts to 1.8.2 at the same).
Regarding the changes I was referring to:
<http://trac.macports.org/changeset?new=61109%40trunk%2Fdports%2F_resources%2Fport1.0%2Fgroup%2Fmuniversal-1.0.tcl&old=54754%40trunk%2Fdports%2F_resources%2Fport1.0%2Fgroup%2Fmuniversal-1.0.tcl>
~suv
p.s. Did you try if gtk-demo has the same alpha-sorting issue in the file chooser dialog on SL?
> Did you try if gtk-demo has the same alpha-sorting issue in the file
> chooser dialog on SL?
yes, I've tried it and it shows the same issue as GIMP does.
BTW, the sort order on my SL system seems to be first by length (including the file extension!) and than alphabetically (again including the file's extension!) and here lower case -> upper case. Can anybody on SL confirm this?
This bug doesn't just affect the file chooser.
For example I'm seeing it in the Font selection dialog of the Text tool in Gimp. Fonts are listed by, it seems, the length of their name, instead of being listed alphabetically.
I think I've found the root of this behaviour. :-)
It's in GLIB. There are some conditional sources that are marked with "HAVE_CARBON". And AFAIK Carbon isn't supported on SL running 64 bit applications. And they still get compiled even if I compile as 64 bit. Same applies to the ld flag '-framework Carbon' which is used when linking GLIB's libraries.
A first attempt to simply undefine HAVE_CARBON will show nearly identical results as in Leopard. Leopard sorts alphabetical, not case sensitive. Now SL sorts alphabetical too, but case sensitive with upper case first. Still not the same sort order, but much more convenient than before :-)
I currently don't know, if disabling the HAVE_CARBON code has some side effects. I'll try some other things too, so please be patient...
ok folks. I've tried various things.
Particially disabling the HAVE_CARBON code in glib/gunicollate.c will use the standard GLIB collation function, which in turn will give a lexicographical sort order. This is nearly the same as in Finder. Althouhg this fix doesn't use OS X functions to create the collation keys, it will give a useable sort order back to Snow Leoapard builds. So I decided to use this code not only on SL but in future builds on Leopard (and Tiger) too to be consistent between the various OS X builds.
The fix will be included in the next releases.
I am experiencing this same issue using the Pan usenet reader. Can you post a patch so we can modify our Portfile? This will enable us to have this bug fixed until an official release comes around, thanks.
Let me rephrase: Can you post a patch for glib2-2.22.4 that will change what you did to get GIMP working? Thanks.