Tor, Thank you for the descriptions on current GTK+2.6.1, and I am excited to hear that the GTK+2.6.1 win32 port will be release some time in the future. Do you have in your mind something about when win32 port will roughly be available. I am considering if I want to wait for the release or to try to build the win32 port by myself.
Regards, Fanz -----Original Message----- From: Tor Lillqvist [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 12:51 PM To: Cui, Fanzhe Cc: [EMAIL PROTECTED]; glade-devel@lists.ximian.com Subject: Win32 port of GTK+2.6.1 Cui, Fanzhe writes: > Does anybody know when the Win32 port will be posted on web, > or any ideas how to make it available? There are still a couple of relatively important (IMHO) open Win32 issues in the GTK+ 2.6.1 sources. As soon as they have been resolved (fixes committed), I will build and release Win32 binaries (i.e. a 2.6.1-timestamp snapshot unless 2.6.2 happens to be relased suitably). A warning to people thinking of building software for Windows against GTK+ 2.6.1: Plase read and ponder what it says in the README file: * GLib 2.6 introduces the concept of 'GLib filename encoding', which is the on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions returning or accepting pathnames have been changed to expect filenames in this encoding, and the common POSIX functions dealing with pathnames have been wrapped. These wrappers are declared in the header <glib/gstdio.h> which must be included explicitly; it is not included through <glib.h>. On current (NT-based) Windows versions, where the on-disk file names are Unicode, these wrappers use the wide-character API in the C library. Thus applications can handle file names containing any Unicode characters through GLib's own API and its POSIX wrappers, not just file names restricted to characters in the system codepage. To keep binary compatibility with applications compiled against older versions of GLib, the Windows DLL still provides entry points with the old semantics using the old names, and applications compiled against GLib 2.6 will actually use new names for the functions. This is transparent to the programmer. When compiling against GLib 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 GLib. * Likewise, g_get_user_name() and g_get_real_name() have been changed to return UTF-8 on Windows, while keeping the old semantics for applications compiled against older versions of GLib. I.e., if you construct file names from strings returned from GLib (g_get_user_name, g_dir_read_name, g_get_current_dir, etc), you *must* use the so-called gstdio wrappers (g_open, g_fopen, etc) with these file names. (No ifdefs needed, it doesn't to use the wrappers on Unix, too, although they don't do anything.) --tml _______________________________________________ Glade-devel maillist - Glade-devel@lists.ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel
