GLib-2.4.5 is now available for download. This is a bug fix release and is source and binary compatible with 2.4.0. The main reason for this release is a bug in the routines converting between filenames and URIs, which can cause problems when used with filenames which are not encoded in UTF-8.
GLib 2.4.5 released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I wonder, who invented that great idea at all
(
I mean, assuming by default that all file names are in UTF-8 (regardless of locale). This is a plain wrong and will cause problems with such files in any non-GLib/GTK program.
Even more strangely, some gnome addicts i talked to told me to change all other apps’ behavior, rather than state this one is incorrect.
And some GNOME apps (namely gftp and, some time ago, rhythmbox) *still* have problems with such (=with names in, say, koi8-r encoding) files.
Well, it isn’t that wrong. The purpose of changing apps is
to convert everything over to UTF-8, which IS a good thing.
Why would anyone use anything else anyway, except for backwards compatibility.
And any non-GLib/GTK apps need not care what glib/gtk apps does, it will be no diffrent from other apps doing whatever
_they_ do.
—
export G_BROKEN_FILENAMES=1
==
The purpose of changing apps is to convert everything over to UTF-8,
==
So GNOME path is to force everyone to follow their ideas?
There are a lot of apps where utf-8 cause problems currently, so i can’t migrate to it.
And, problems in gftp and rhythmbox happen even if G_BROKEN_FILENAMES is set.
————-
==
The purpose of changing apps is to convert everything over to UTF-8,
==
So GNOME path is to force everyone to follow their ideas?
————-
Erm… their ideas? Do you know what UTF-8 is? It wasn’t their idea at all.
Ha, even with all the problems with UTF-8 (I haven’t encountered any), that’s still far and far better than the unicode mess in Windows.
I spent some time writing a Windows app that has to deal with Korean encodings. Dealing with all the unicode stuff is an entire pain in the *** compared to Linux/glib:
– Apparently you can’t pass a unicode string as a filename to file writing functions. You’ll have to use special unicode Win32 API functions.
– Pre-Win2k versions of Windows do not support unicode at all, which breaks my app in various ways.
– Other similar apps out there may or may not handle unicode. My app’s output may be unusable for some of those apps depending on whether they use unicode or not, and how.
– A friend of mine was told to create a folder with the name “¾ÆÀÌÅÛ” (this is supposed to be Korean text). He copied and pasted that in Windows Explorer, but it shows “??????” instead, and sometimes even Japanese characters (which is not Korean). Eventually he gave up and uploaded the files to a Linux server, where he was able to type ‘mkdir ¾ÆÀÌÅÛ’.
– And other problems.
In Linux, everything is already UTF-8, or switching to UTF-8. Got some Chinese document? No problem, it displays correct out-of-the-box. Korean filenames? No problem, it just works. In Windows, internationalization support is a huge mess.
It’s important to be able to write both イロハニホヘト and Nürnberg Heizölrückstoßabdämpfung on a computer. I’m mostly writing this to see whether OSNews does the Right Thing.
On Linux at least the OS filesystem APIs are defined only in UTF-8 and therefore anyone using something else does so at their own risk. I can understand that if you began using a Linux desktop system in 1995 and your native language uses a non-Latin alphabet this will be an uncomfortable transition, but it’s better for everyone this way.
Newer distros (say Fedora Core for example) use UTF-8 practically everywhere right from the outset.
This is bullshit.
API is defined to work with asciiz strings.
That is, 8 bit symbols, zero terminated.
UTF8 is thing you _may_ use. You don’t _have_ to.
I have a sneaky suspcion that there is some misunderstanding going on here …
Certainly you are not saying that UTF-8 is a GNOME idea ?
Certainly you are not confusing 7+1 bit ASCII-the american standard for information interchange with what UTF-8 is ?
Certainly you are not complaining that slowly but surely Linux is completely moving to UTF-8 away from the horrid nightmare of incompatible encodings ?
Please enlighten us as to what you are really trying to say….
.. is the future of character encodings on Linux. Apps that don’t use it or have bugs with it need to be fixed, simple as that. Glib is quite right to use it by default.