Le vendredi 18 août 2006 14:31, Christian Marillat a écrit :
> G_BROKEN_FILENAME ainsi que G_FILENAME_ENCODING était documenté dans le
> README tu paquet libgtk2.0-0 mais le fichier à disparu...
Il est toujours dans la testing, pour l'instant (version 2.8.18-1). Voici le
passage intéressant :
* On Unix, the assumption of GLib and GTK+ by default is that filenames on
the filesystem are encoded in UTF-8 rather than the encoding of the
locale;
the GTK+ developers consider that having filenames whose interpretation
depends on the current locale is fundamentally a bad idea.
If you have filenames encoded in the encoding of your locale, then you
may want to set the G_FILENAME_ENCODING environment variable:
G_FILENAME_ENCODING=@locale
export G_FILENAME_ENCODING
(Earlier versions of GLib 2.x required a different environment variable
setting; G_BROKEN_FILENAMES=1 to achieve the same effect; this
is still supported, but G_FILENAME_ENCODING is preferred.)
Best integration of GTK+ 2.6 with the environment is achieved by
using a UTF-8 locale.
On Windows, filenames passed to GTK+ should always be in UTF-8, as
in GLib 2.6. This is different than in previous versions of GTK+
where the system codepage was used. As in GLib, for DLL ABI
stability, applications built against previous versions of GTK+ will
use entry points providing the old semantics.
When compiling against GTK+ 2.6, applications intended to be
portable to Windows must take the UTF-8 file name encoding into
consideration, and use the gstdio wrappers to access files whose
names have been constructed from strings returned from GTK+ or GLib.
En positionnant G_FILENAME_ENCODING=@locale, ça marche effectivement bien.
Sauf avec gcfilms :o/ Bon, de toute façon, ce truc plante trop souvent pour
être vraiment utilisable. Le plus bizarre, c'est que gcstar fait pareil...
--
Frédéric
http://www.gbiloba.org
