dynamic loading, and an object system.
The official ftp site is:
- ftp://ftp.gtk.org/pub/gtk
+ ftp://ftp.gtk.org/pub/glib
The official web site is:
http://www.gtk.org/
Information about mailing lists can be found at
- http://www.gtk.org/mailinglists.html
+ http://www.gtk.org/mailing-lists.html
To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null
(Send mail to gtk-list-request@gnome.org with the subject "subscribe")
See the file 'INSTALL'
-Notes about GLib-2.0.0
+Notes about GLib 2.28
+=====================
+
+* The GApplication API has changed compared to the version that was
+ included in the 2.25 development snapshots. Existing users will need
+ adjustments.
+
+Notes about GLib 2.26
+=====================
+
+* Nothing noteworthy.
+
+Notes about GLib 2.24
+=====================
+
+* It is now allowed to call g_thread_init(NULL) multiple times, and
+ to call glib functions before g_thread_init(NULL) is called
+ (although the later is mainly a change in docs as this worked before
+ too). See the GThread reference documentation for the details.
+
+* GObject now links to GThread and threads are enabled automatically
+ when g_type_init() is called.
+
+* GObject no longer allows to call g_object_set() on construct-only properties
+ while an object is being initialized. If this behavior is needed, setting a
+ custom constructor that just chains up will re-enable this functionality.
+
+* GMappedFile on an empty file now returns NULL for the contents instead of
+ returning an empty string. The documentation specifically states that code
+ may not rely on nul-termination here so any breakage caused by this change
+ is a bug in application code.
+
+Notes about GLib 2.22
+=====================
+
+* Repeated calls to g_simple_async_result_set_op_res_gpointer used
+ to leak the data. This has been fixed to always call the provided
+ destroy notify.
+
+Notes about GLib 2.20
+=====================
+
+* The functions for launching applications (e.g. g_app_info_launch() +
+ friends) now passes a FUSE file:// URI if possible (requires gvfs
+ with the FUSE daemon to be running and operational). With gvfs 2.26,
+ FUSE file:// URIs will be mapped back to gio URIs in the GFile
+ constructors. The intent of this change is to better integrate
+ POSIX-only applications, see bug #528670 for the rationale. The
+ only user-visible change is when an application needs to examine an
+ URI passed to it (e.g. as a positional parameter). Instead of
+ looking at the given URI, the application will now need to look at
+ the result of g_file_get_uri() after having constructed a GFile
+ object with the given URI.
+
+Notes about GLib 2.18
+=====================
+
+* The recommended way of using GLib has always been to only include the
+ toplevel headers glib.h, glib-object.h and gio.h. GLib enforces this by
+ generating an error when individual headers are directly included.
+ To help with the transition, the enforcement is not turned on by
+ default for GLib headers (it is turned on for GObject and GIO).
+ To turn it on, define the preprocessor symbol G_DISABLE_SINGLE_INCLUDES.
+
+Notes about GLib 2.16
+=====================
+
+* GLib now includes GIO, which adds optional dependencies against libattr
+ and libselinux for extended attribute and SELinux support. Use
+ --disable-xattr and --disable-selinux to build without these.
+
+Notes about GLib 2.10
+=====================
+
+* The functions g_snprintf() and g_vsnprintf() have been removed from
+ the gprintf.h header, since they are already declared in glib.h. This
+ doesn't break documented use of gprintf.h, but people have been known
+ to include gprintf.h without including glib.h.
+
+* The Unicode support has been updated to Unicode 4.1. This adds several
+ new members to the GUnicodeBreakType enumeration.
+
+* The support for Solaris threads has been retired. Solaris has provided
+ POSIX threads for long enough now to have them available on every
+ Solaris platform.
+
+* 'make check' has been changed to validate translations by calling
+ msgfmt with the -c option. As a result, it may fail on systems with
+ older gettext implementations (GNU gettext < 0.14.1, or Solaris gettext).
+ 'make check' will also fail on systems where the C compiler does not
+ support ELF visibility attributes.
+
+* The GMemChunk API has been deprecated in favour of a new 'slice
+ allocator'. See the g_slice documentation for more details.
+
+* A new type, GInitiallyUnowned, has been introduced, which is
+ intended to serve as a common implementation of the 'floating reference'
+ concept that is e.g. used by GtkObject. Note that changing the
+ inheritance hierarchy of a type can cause problems for language
+ bindings and other code which needs to work closely with the type
+ system. Therefore, switching to GInitiallyUnowned should be done
+ carefully. g_object_compat_control() has been added to GLib 2.8.5
+ to help with the transition.
+
+Notes about GLib 2.6.0
======================
-* On systems without the libintl from GNU gettext() or a recent version
- of the GNU C library, the encoding of translated error messages will be
- incorrect (they should be in UTF-8). A workaround for this is to install
- GNU gettext and use that libintl. This is expected to be fixed in GLib-2.0.1.
- Application programmers should not call g_locale_to_utf8() on these
- strings.
-
-* Similarly, the GLib error logging functions such as g_print(), g_warning(),
- g_error(), currently do not convert the strings they are passed from
- UTF-8 to the encoding of the locale, or check that the strings they
- are passed are valid UTF-8. They should, despite this, be assumed to take
- UTF-8 arguments.
-
+* 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.
+
+* The GLib uses an '_' prefix to indicate private symbols that
+ must not be used by applications. On some platforms, symbols beginning
+ with prefixes such as _g will be exported from the library, on others not.
+ In no case can applications use these private symbols. In addition to that,
+ GLib+ 2.6 makes several symbols private which were not in any installed
+ header files and were never intended to be exported.
+
+* To reduce code size and improve efficiency, GLib, when compiled
+ with the GNU toolchain, has separate internal and external entry
+ points for exported functions. The internal names, which begin with
+ IA__, may be seen when debugging a GLib program.
+
+* On Windows, GLib no longer opens a console window when printing
+ warning messages if stdout or stderr are invalid, as they are in
+ "Windows subsystem" (GUI) applications. Simply redirect stdout or
+ stderr if you need to see them.
+
+* The child watch functionality tends to reveal a bug in many
+ thread implementations (in particular the older LinuxThreads
+ implementation on Linux) where it's not possible to call waitpid()
+ for a child created in a different thread. For this reason, for
+ maximum portability, you should structure your code to fork all
+ child processes that you want to wait for from the main thread.
+
+* A problem was recently discovered with g_signal_connect_object();
+ it doesn't actually disconnect the signal handler once the object being
+ connected to dies, just disables it. See the API docs for the function
+ for further details and the correct workaround that will continue to
+ work with future versions of GLib.
How to report bugs
==================
-Bugs should be reported to the GNOME bug tracking system.
+Bugs should be reported to the GNOME bug tracking system.
(http://bugzilla.gnome.org, product glib.) You will need
to create an account for yourself.
And anything else you think is relevant.
-* How to reproduce the bug.
+* How to reproduce the bug.
- If you can reproduce it with the testgtk program that is built
- in the gtk/ subdirectory, that will be most convenient. Otherwise,
- please include a short test program that exhibits the behavior.
- As a last resort, you can also provide a pointer to a larger piece
+ If you can reproduce it with one of the test programs that are built
+ in the tests/ subdirectory, that will be most convenient. Otherwise,
+ please include a short test program that exhibits the behavior.
+ As a last resort, you can also provide a pointer to a larger piece
of software that can be downloaded.
* If the bug was a crash, the exact text that was printed out
Otherwise, enter a new bug report that describes the patch,
and attach the patch to that bug report.
-Bug reports containing patches should include the PATCH keyword
-in their keyword fields. If the patch adds to or changes the GLib
-programming interface, the API keyword should also be included.
-
-Patches should be in unified diff form. (The -u option to GNU
-diff.)
+Patches should be in unified diff form. (The -up option to GNUdiff.)