| General Information |
| =================== |
| |
| This is GLib version 2.4.7. GLib is the low-level core |
| library that forms the basis for projects such as GTK+ and GNOME. It |
| provides data structure handling for C, portability wrappers, and |
| interfaces for such runtime functionality as an event loop, threads, |
| dynamic loading, and an object system. |
| |
| The official ftp site is: |
| ftp://ftp.gtk.org/pub/gtk |
| |
| The official web site is: |
| http://www.gtk.org/ |
| |
| Information about mailing lists can be found at |
| http://www.gtk.org/mailinglists.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") |
| |
| Installation |
| ============ |
| |
| See the file 'INSTALL' |
| |
| Notes about GLib-2.4.0 |
| ====================== |
| |
| * g_filename_to_uri() used to operate like this: |
| |
| 1. convert the filename from G_FILENAME_ENCODING to UTF-8 |
| 2. encode the UTF-8 into hexadecimal escapes for URIs |
| |
| This was incorrect, and now the filename is simply escaped for |
| conversion into URIs. g_filename_from_uri() is fixed in the same |
| fashion. Programs which store the converted URIs or filenames may |
| need manual conversion. |
| |
| * GObject now enforces CONSTRUCT_ONLY properties; due to an oversight |
| in previous versions, it was possible to set CONSTRUCT_ONLY properties |
| after construct time. |
| |
| * 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. |
| (http://bugzilla.gnome.org, product glib.) You will need |
| to create an account for yourself. |
| |
| In the bug report please include: |
| |
| * Information about your system. For instance: |
| |
| - What operating system and version |
| - For Linux, what version of the C library |
| |
| And anything else you think is relevant. |
| |
| * 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 |
| of software that can be downloaded. |
| |
| * If the bug was a crash, the exact text that was printed out |
| when the crash occured. |
| |
| * Further information such as stack traces may be useful, but |
| is not necessary. |
| |
| Patches |
| ======= |
| |
| Patches should also be submitted to bugzilla.gnome.org. If the |
| patch fixes an existing bug, add the patch as an attachment |
| to that bug report. |
| |
| 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.) |