Running JuK here, KDE 3.5.1, latest ~x86. Problem on Gentoo is that ordering alphabetically e.g. by Artist is not working quite 100% correctly. An example- The first Artist that should start with the letter 'A' is 'A Silver Mt. Zion'. However, it appears to ignore the space and treat it as 'ASilver', so that artists e.g. Air, Aphex Twin, appear above them in the list. I'm dual-booting with FreeBSD 6 here, running JuK/KDE 3.5.1 through ports, and alphabeticising appears to work fine there, so unless FreeBSD port is patching JuK, I don't think this is an upstream thing. Q. Does JuK use some backend for sorting, or is it internal? emerge info Portage 2.1_pre4-r1 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-gentoo-r3 i686) ================================================================= System uname: 2.6.15-gentoo-r3 i686 AMD Athlon(tm) XP Gentoo Base System version 1.12.0_pre15 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fprefetch-loop-arrays -ftracer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fprefetch-loop-arrays -ftracer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LC_ALL="en_GB.UTF-8" LINGUAS="en en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://foucault/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac acpi apache2 arts artswrappersuid asf audiofile avi berkdb bitmap-fonts browserplugin bzip2 cairo cdparanoia cdr crypt css cups curl dbus dga dts dv dvd dvdr dvdread eds emboss encode exif expat extrafilters ffmpeg firefox flac foomaticdb fortran gdbm geoip gif gimpprint glibc-omitfp glitz glut gphoto2 gpm gtk gtk2 hal idn imagemagick imlib joystick jpeg jpeg2k kde kdeenablefinal lcms libg++ libwww logrotate mad mikmod mjpeg mmx mmxext mng modplug motif mp3 mpeg musepack musicbrainz ncurses nfs nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl oss pam pdf pdflib perl pic png ppds python qt quicktime readline real rtc sdl sndfile speex spell sqlite sse ssl svg tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vcd vorbis win32codecs wmf xcomposite xine xml xml2 xmms xscreensaver xv xvid xvmc yv12 zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en linguas_en_GB userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LDFLAGS
Probably locale-dependent. What is the locale you use on Gentoo Linux and what on FreeBSD ?
Locale is en_GB.UTF-8 here on Gentoo, I don't recall setting up my Locale in FreeBSD so probably the default there (C? I'm no expert on locales).
Seems I have set my locale on FreeBSD to en_GB.ISO8859-15 I'm not sure how to get that locale on Gentoo; locale -a gives my only en_GB options as en_GB and the UTF-8 one I'm using. I'm using userlocales for glibc build; /etc/locales.build has the following en_GB entries- en_GB/ISO-8859-1 en_GB/ISO-8859-15 en_GB.UTF-8/UTF-8
Tried setting locale to en_GB in /etc/env.d/20locale, rebooted, no change in JuK, still not ordering correctly.
I can reproduce this - and with Amarok as well, so the source of the problem lies deeper. (In reply to comment #1) > Probably locale-dependent. Well, umlauts work fine and since QListview uses localeAwareCompare(), which itself looks fine to me, I have absolutely no clue what the problem is.
Wait, amaroK uses ordering from the backend database, and SQLite sucks as ordering.
(In reply to comment #6) > Wait, amaroK uses ordering from the backend database, and SQLite sucks as > ordering. Ordering happens in the Listviews, they're not MVC components - if I do not miss anything. Also I'm using Postgres, not SQLite.
If you're referring to amaroK's collection browser, the ordering is not handled by the listview but by amaroK "by hand" (look the "Unknown" and "Various artists" entries at top and bottom). For PostgreSQL you have to enable collations, I'm actually not 100% sure how it's done, I haven't yet looked at it also if I'd like to have it working.
(In reply to comment #8) > If you're referring to amaroK's collection browser, the ordering is not handled > by the listview but by amaroK "by hand" (look the "Unknown" and "Various > artists" entries at top and bottom). Ah, assumed it would. I did only look at Juk's code. The Amarok 1.3.x playlist listview is horrible slow with a larger playlist btw..
To be more exact: I could see this with both the collection tree and the playlist in Amarok.
Yes it is slow, that's what dynamic mode was created for :)
Is this still an issue with juk-3.5.5?
(In reply to comment #12) > Is this still an issue with juk-3.5.5? > Yes (well, 3.5.6 here now).
Can you file a bug upstream and post the URL here?
(In reply to comment #14) > Can you file a bug upstream and post the URL here? > I don't know that it's an upstream bug - if you read my OP, you'll see JuK (3.5.4) works correctly here on FreeBSD 6.x. I can't comment on any other Linux distros - I only use Gentoo. I don't think it's sqlite related either, as JuK uses that in FreeBSD too.
Created attachment 121010 [details] juk_sort_LC_ALL_non_C.png LC_ALL set to a non-C value.
Created attachment 121012 [details] juk_sort_LC_ALL_C.png LC_ALL set to C.
Of course, it's locale-dependent. With LC_ALL=C the sorting as one would expect. I leave it as an exercise for the reader to figure out which individual LC_* variable does it. So, please either file an upstream bug or let me know if I should close this as invalid.
If this is a bug at all, it's upstream.
