glib2: revert to OS X sorting (alphabetical, not case-sensitive) on Mac OS X 10.5.8 Leopard

[su-v]

In revision r64476 to address ticket #23959, sorting was changed for all platforms although the bug only occurs when building & using glib2 on Snow Leopard (x86_64).

Could the patch added in r64476 be made conditional, so that at least on Leopard, sorting (of fonts, filenames, etc.) uses again the same sort order like before (alphabetical, not case-sensitive), like e.g. in the Finder and native file dialogs?

Upstream bug report for glib is ​Bug 612019 - Alphabetical sorting not working in OSX Snow Leopard 10.6.x

Attached patch was used to quickly test sorting order without changes to 'glib/gunicollate.c' (it patchfiles-deletes the earlier added patchfile if platform is 'darwin i386') - possibly the test could be done in the patch instead?

[ryandesign (Ryan Carsten Schmidt)]

Perhaps you don't realize that "platform i386" applies on all Intel architectures -- i386 and x86_64 (just as "platform powerpc" applies on all PowerPC architectures -- ppc and ppc64).

[su-v]

Main point of the ticket was to discuss if the patch from r64476 could be applied selectively (only on Snow Leopard, or those system where file sorting was broken - AFAICT the bug never affected Leopard) - whatever Portfile magic is best, I don't know, I'm still learning ;) .

I tested building glib2 on Mac OS X 10.5.8 i386 without having the patch to 'glib/gunicollate.c' applied (i.e. having <CoreServices/CoreServices.h> included), and the sorting e.g. in GTK+ font selectors and file browsers is what users expect on Mac OS X (not case-sensitive) and how it used to be on Leopard, before the problems on Snow Leopard had been noticed and addressed by not including the CoreServices header file.

[jmroot (Joshua Root)]

Are you sure it works on 10.5/x86_64 (or indeed ppc64) and doesn't work on 10.6/i386? It doesn't look like that would be the case going by the discussion in the upstream bug.

[su-v]

Replying to jmr@…:

Are you sure it works on 10.5/x86_64 (or indeed ppc64) and doesn't work on 10.6/i386? It doesn't look like that would be the case going by the discussion in the upstream bug.

No, I'm not sure about 10.5.8/x86_64 (or ppc64) nor 10.6/i386 - I only have access to 10.5.8/i386.

The patchfile added in r64476 has this comment: /* Carbon is not available on 64-bit */, but nothing is done to test for 64-bit, and HAVE_CARBON is undefined anyway (originally this was decided by the maintainer for the packaged versions of GIMP on OS X, to have GIMP behave consistently on all supported platforms [*]).

Could the patch file include a test for 64bit, like e.g. in this GIMP patch file​, only reversed (i.e. if __LP64__ is defined, undefine HAVE_CARBON)?

[*] from the ​related bug report in the bug tracker of GIMP on OS X:

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.

[kencu (Ken)]

presumably fixed sometime in the last decade :>

please reopen with new info if otherwise.

[4008d825550f7545a4fdd9f06e3633990ab6c625/macports-ports]