mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-05-31 18:00:06 +02:00
37e4b8c87e
Wed Mar 7 09:36:33 2001 Tim Janik <timj@gtk.org>
* gboxed.[hc]: changed prototype of g_boxed_type_register_static()
to contain an optional init function and a hint at whether the
boxed structure uses ref counting internally.
added g_value_set_boxed_take_ownership().
made G_TYPE_BOXED an abstract value type.
* genums.[hc]: made G_TYPE_ENUM and G_TYPE_FLAGS abstract value
types.
* glib-genmarshal.c: argument type changes, preparation for third-party
arg specification.
* gobject.[hc]: cleaned up get/set property code.
added g_strdup_value_contents() to improve warnings.
* gparam.[hc]: added g_param_value_convert(), taking over responsibility
of the old g_value_convert(). added G_PARAM_LAX_VALIDATION flag so
validation alterations may be valid a part of the property setting
process.
* gparamspecs.[hc]: made value comparisons stable (for sort applications).
added GParamSpecValueArray, a param spec for value arrays and
GParamSpecClosure. nuked the value exchange functions and
GParamSpecCCallback.
* gtype.[hc]: catch unintialized usages of the type system with
g_return_val_if_uninitialized(). introduced G_TYPE_FLAG_VALUE_ABSTRACT
to flag types that introduce a value table, but can't be used for
g_value_init(). cleaned up reserved type ids.
* gvalue.[hc]: code cleanups and saner checking.
nuked the value exchange API. implemented value transformations, we
can't really "convert" values, rather transforms are an anylogy to
C casts, real conversions need a param spec for validation, which is
why g_param_value_convert() does real conversions now.
* gvaluearray.[hc]: new files that implement a GValueArray, a struct
that can hold inhomogeneous arrays of value (to that extend that it
also allowes undefined values, i.e. G_VALUE_TYPE(value)==0).
this is exposed to the type system as a boxed type.
* gvaluetransform.c: new file implementing most of the former value
exchange functions as single-sided transformations.
* gvaluetypes.[hc]: nuked G_TYPE_CCALLBACK, added
g_value_set_string_take_ownership().
* *.h: s/G_IS_VALUE_/G_VALUE_HOLDS_/.
* *.[hc]: many fixes and cleanups.
* many warning improvements.
Tue Feb 27 18:35:15 2001 Tim Janik <timj@gtk.org>
* gobject.c (g_object_get_valist): urg, pass G_VALUE_NOCOPY_CONTENTS
into G_VALUE_LCOPY(), this needs proper documenting.
* gparam.c: fixed G_PARAM_USER_MASK.
* gtype.c (type_data_make_W):
(type_data_last_unref_Wm): fixed invalid memory freeing.
* gobject.c (g_object_last_unref): destroy signal handlers associated
with object, right before finalization.
* gsignal.c (g_signal_parse_name): catch destroyed nodes or signals
that don't actually support details.
* gobject.[hc]: got rid of property trailers. nuked GObject
properties "data" and the "signal" variants.
(g_object_connect): new convenience function to do multiple
signal connections at once.
(g_object_disconnect): likewise, for disconnections.
* gparam.[hc] (g_param_spec_pool_lookup): took out trailer support.
* gvalue.[hc]: marked g_value_fits_pointer() and g_value_peek_pointer()
as private (the latter got renamed from g_value_get_as_pointer()).
Wed Mar 7 09:32:06 2001 Tim Janik <timj@gtk.org>
* glib-object.h: add gvaluearray.h.
* gstring.[hc]: fixup naming of g_string_sprint*.
* gtypes.h: fixed GCompareDataFunc naming.
Wed Mar 7 09:33:27 2001 Tim Janik <timj@gtk.org>
* gobject/Makefile.am: shuffled rules to avoid excessive
rebuilds.
* gobject/gobject-sections.txt: updates.
* gobject/tmpl/*: bunch of updates, added another patch
from Eric Lemings <eric.b.lemings@lmco.com>.
*** IMPORTANT *** This is a development version of GLib. You should be using a stable version, which is available at ftp://ftp.gtk.org/pub/gtk/v1.2/. This version is meant for developers of GLib only: * You should not base stable software on this version of GLib. * GNOME developers should use a stable version of GLib. Distributions should *NOT* ship a development package of this GLib. Do not ship the headers and do not ship the glib-config script. These things will conflict with the stable 1.2 series. Package only enough to satisfy the requirements of some other package. Package only the library itself. Doing otherwise will do no favors to the community. If you install this version of GLib, we strongly recommend that you install it in a different prefix than GLib 1.2. Use --prefix as an argument to configure to do this. Otherwise, you will not be able to do development with GLib 1.2 any longer. *** You should be using GLib 1.2 instead. *** General Information =================== This is GLib version 1.3.1. GLib is a library which includes support routines for C such as lists, trees, hashes, memory allocation, and many other things. The official ftp site is: ftp://ftp.gtk.org/pub/gtk The official web site is: http://www.gtk.org/ A mailing list is located at: gtk-list@redhat.com To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null (Send mail to gtk-list-request@redhat.com with the subject "subscribe") Installation ============ See the file 'INSTALL' How to report bugs ================== To report a bug, send mail either to gtk-list, as mentioned above, or to gtk-bugs@gtk.org. If you send mail to gtk-list, you must be subscribed yourself. In the mail include: * The version of GLib * Information about your system. For instance: - What operating system and version - What version of X - 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 testglib program that is built in the glib/ directory, 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 can be uploaded to the incoming/ directory on ftp.gtk.org. Please follow the instructions there, and include your name and email address in the README file. If the patch fixes a bug, it is usually a good idea to include all the information described in "How to Report Bugs".