[FreeBSD port]: devel/glib20

[Alexander Nedotsukov]

On 04.03.2009, at 5:40, Stanislav Sedov wrote:

> On Fri, 27 Feb 2009 15:38:51 +0900
> Alexander Nedotsukov <bland at FreeBSD.org> mentioned:
>
>>
>> Stanislav,
>>
>> This "nasty" GLib behavior is for a reason. Well at least from the  
>> CJK
>> biased GLib developers point of view :-) The belief is there are  
>> reasonable
>> amount of users who switches between UTF and non-UTF locales often.  
>> ATM
>> GLib tries to validate filename as UTF-8 encoded first and fallback  
>> to the
>> current locale encoding if it is not. This does not look normal to  
>> me but
>> anyway.
>>
>
> However, it seems that this autodetection does not work. OTOH, it  
> seem to work
> fine with G_BROKEN_FILENAMES set. Do you think it will harm to have  
> this
> behavior as default?
>
The fact it "does not work" may mean anything from bug in GLib to API  
misuse in the client code.
And I think I am not brave enough to take responsibility pissing  
against upstream :-)
My opinion is for good or bad we have to follow GLib guidelines. Which  
clearly state this:

* 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.

Again. This is not a bug as you state. If you want this to be  
reconsidered you have to go upstream.
Note. I am not against this option per-se. Though the default must be  
leaved as is.