Don't emit property deprecation warnings for construct properties that
are being set to their default value during construction, but _do_ emit
them in all cases when the property was explicitly given to
g_object_new().
https://bugzilla.gnome.org/show_bug.cgi?id=732184
By default G_PARAM_DEPRECATED means absolutely nothing. We only emit a
warning if G_ENABLE_DIAGNOSTIC is set to '1' and then, only on sets.
Turn the logic on its head: emit the warning by default, unless
G_ENABLE_DIAGNOSTIC is set to 0. In order to avoid a torrent of output, only
emit a warning once per property name.
https://bugzilla.gnome.org/show_bug.cgi?id=732184
Leave ourselves a little wiggle room: if people install properties after
initialisation then we reserve the right to handle that in a way that
may not be threadsafe.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Add a flag to prevent the automatic emission of the "notify" signal
during g_object_set_property().
If this flag is set then the class must explicitly emit the notify
for themselves. This is already standard practice on most classes, but
we cannot simply remove the existing behaviour because there are surely
many cases where it is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=731200
Construct properties are always set during construction.
It makes no sense to warn about this even if the property
is marked as deprecated; the deprecation warning should
only be issues for explicit uses of the property after
construction.
https://bugzilla.gnome.org/show_bug.cgi?id=730045
Although returning NULL from constructor is strongly discouraged, some
old libraries need to keep doing it for ABI-compatibility reasons.
Given this, it's rude to forbid finalization from within
constructor(), since it would otherwise work correctly now anyway (and
the critical when returning NULL should discourage any new uses of
returning NULL from constructor()).
https://bugzilla.gnome.org/show_bug.cgi?id=661576
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
This is really just a very crude and limited conditional breakpoint.
Update the documentation to explain conditional breakpoints in
gdb instead. Also, remove the link to refdbg, which appears dead.
https://bugzilla.gnome.org/show_bug.cgi?id=719687
The signals queued while notify is frozen are emitted in
reverse order, while omitting duplicates. The lack of documentation
for this was pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=607016
Rather than keeping a global list of objects that are being
constructed, use qdata on the object itself like we do with several
other properties now.
https://bugzilla.gnome.org/show_bug.cgi?id=661576
If a constructor() implementation created an object but then unreffed
it rather than returning it, that object would get left on the
construction_objects list, which would cause problems later when that
memory location got reused by another object.
"Fix" this by making it fail intentionally, and add a test for it (and
for the normal, working singleton case).
https://bugzilla.gnome.org/show_bug.cgi?id=661576
Just like g_object_notify, check for a zero ref_count in
g_object_notify_by_pspec and leave if it is 0.
This allows using functions in ->finalize() that possibly also
notify a property change on the object. Previously,
this resulted in an error from g_object_ref.
https://bugzilla.gnome.org/show_bug.cgi?id=705570
We have turned up enough cases of this being done (including GTK API
allowing apps to do this to GtkSettings well after it has been
instantiated) that it is clear that we cannot really break this feature
while claiming to be backwards compatible.
For that reason, it becomes a warning rather than a critical (ie: it is
still well-defined behaviour, but you are discouraged from doing it).
The intention is to keep this feature for at least the next while.
A given GObjectClass will be able to avoid using GParamSpec pool for as
long as you don't install properties after init. If you do that, you
will get a warning and we will devolve to using GParamSpecPool.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
A previous patch asserted that this was not true and we had to revert it
because it broke the shell. Instead of reverting, we should have used a
critical, so do that now.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
There is some code in the wild (like in gnome-session) that does this
from its custom _constructor() implementation:
{
GObject *obj;
obj = ((chain up));
if (!object_is_viable (obj))
{
g_object_unref (obj);
return NULL;
}
else
return obj;
}
This has never been a valid use of GObject and this code has always
caused memory to be leaked[1] by growing the construction_objects list.
The ability to legitimately return NULL from a constructor was exactly
the reason that we created GInitable, in fact.
That doesn't change the fact that the g_object_new() rewrite will crash
in this case, so instead of doing that, let's emit a critical and avoid
the crash. This will allow people to upgrade their GLib without also
upgrading their gnome-session. Meanwhile, people can fix their broken
code.
[1] not in the strictest sense of the word, because it's still reachable
Make a number of improvements to g_object_new():
- instead of looking up the GParamSpec for the named property once in
g_object_new() (in order to collect) and then again in g_object_newv
(when actually setting the property), g_object_new_internal() is a
new function that takes the GParamSpec on the interface to avoid the
second lookup
- in the case that ->constructor() is not set, we need not waste time
creating an array of GObjectConstructParam to pass in. Just directly
iterate the list of parameters, calling set_property() on each.
- instead of playing with linked lists to keep track of the construct
properties, realise that the number of construct properties that we
will set is exactly equal to the length of the construct_properties
list on GObjectClass and the only thing that may change is where the
value comes from (in the case that it was passed in)
This assumption was already implicit in the existing code and can be
seen from the sizing of the array used to hold the construct
properties, but it wasn't taken advantage of to make things simpler.
- instead of allocating and filling a separate array of the
non-construct properties just re-iterate the passed-in list and set
all properties that were not marked G_PARAM_CONSTRUCT (since the ones
that were construct params were already used during construction)
- use the new g_param_spec_get_default_value() API instead of
allocating and setting the GValue for each construct property that
wasn't passed from the user
Because we are now iterating the linked list of properties in-order we
need to append to that list during class initialising instead of
prepending.
These changes show a very small improvement on the simple-construction
performance testcase (probably just noise) and they improve the
complex-construction case by ~30%.
Thanks to Alex Larsson for reviews and fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
This reverts commit ddb0ce1421.
Colin's smoke testing has found issues in at least gjs and
gnome-settings-daemon. We'll need to see if we can address those.
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
Prevent this from happening. Require that all properties are installed by
the time class_init has finished.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
This reverts commit 028d4a03f2.
I thought that we would be able to get away with this incompatible
change but it appears to impact far too much existing code. The only
thing we can do is revert.
https://bugzilla.gnome.org/show_bug.cgi?id=688596
Move the constructed() call to happen after all of the properties are
set (not just the construct properties).
This is an incompatible change but we are making it under the belief
that it should be safe. If this change impacts you in a negative way
please comment on the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=685733
Expand the documentation for g_object_[freeze|thaw]_notify() to explain that
it deduplicates “notify” signals emitted by frozen objects, so that at most
one signal is emitted per property.
https://bugzilla.gnome.org/show_bug.cgi?id=676937
Transparent access to a weak pointer from the thread performing the
weak -> strong conversion is incompatible with thread-safety: that
thread will have to do something special. This is GNOME#548954.
https://bugzilla.gnome.org/show_bug.cgi?id=548954
We were previously preventing implementations of an interface from
specifying G_PARAM_CONSTRUCT for a property of that interface if the
interface didn't specify it itself (or was readonly).
This is something that should only interest the implementation, so we
remove this restriction.
This allows 6 new possible override scenarios:
- writable -> writable/construct
- writable -> readwrite/construct
- readwrite -> readwrite/construct
- writable/construct-only -> writable/construct
- writable/construct-only -> readwrite/construct
- readwrite/construct-only -> readwrite/construct
and we update the testcase to reflect this.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Change the order of the checks so that we hear about the 'biggest'
problem first. Also, stop reporting problems after we report the first
one for a particular property.
Add some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
The property override typecheck was meant to enforce the type on the
overriding property being exactly equal to the type on the interface
property. Instead, g_type_is_a() was incorrectly used.
We could try to enforce equality, but if a property is read-only then it
should be possible for the implementation to type the property with any
subtype of the type specified on the interface (because returning a more
specific type will still satisfy the interface). Likewise, if the
property is write-only then it should be possible for the implementation
to type the property with any supertype.
We implement the check this way.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Simplify some of the logic in this function.
1) Simplify flag checks as per Colin's suggestions in
https://bugzilla.gnome.org/show_bug.cgi?id=605667
2) Don't repeatedly recheck if class_pspec is NULL.
GObject enforces the following restrictions on property overrides:
- must only add abilities: if the parent class supports
readability/writability then the subclass must also support them.
Subclasses are free to add readability/writability.
- must not add additional restrictions: if the parent class doesn't
have construct/construct-only restrictions then the subclass must
not add them. Subclasses are free to remove restrictions.
The problem with the previous implementation is that the check against
adding construct/construct-only restrictions was being done even if the
property was not previously writable. As an example:
"readable" and "writable only on construct"
was considered as being more restrictive than
"read only".
This patch tweaks the check to allow the addition of
construct/construct-only restrictions for properties that were
previously read-only and are now being made writable.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600161
When the 'conditional' parameter is TRUE, the queue will only be frozen
(ie: have its freeze count increase by one) if it is already frozen.
This will allow us to avoid a freeze-notify-thaw in the case that we
just want to notify on a single property.
Another approach may have been to add an is_frozen() type call and avoid
even increasing the freeze count at all in this case. Unfortunately,
I'm not totally sure what is the exact expected semantics of
simultaneous notifications in multiple threads and this may interact
badly with someone freezing or thawing in between our check and
emission.
Lift the check-if-READABLE and redirect-target logic from out of
g_object_notify_queue_add() into its own function, get_notify_pspec().
Use that function at the site of our two calls to
g_object_notify_queue_add().
This was done as a separate file before, and #include brought it into
gobject.c. That's a bit mad, so stop doing that.
Unfortunately, the insanity steps up a level: gobjectnotifyqueue.c is
installed in the public include dir, so we can't just get rid of it
entirely.
Similar to G_PARAM_DEPRECATED. It will warn only for users of the
signals, so a signal can still be emited without warning, for
compatibility reasons.
Apparently, there is no way user flags could have been used before,
so that shouldn't break anyone.
https://bugzilla.gnome.org/show_bug.cgi?id=663581
Some links were broken due to typos, because functionality was removed
in GLib 2.0 or for various other reasons. Fix up as many of them as is
reasonable.
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
I couldn't tell from reading the documentation whether I had to pass in
an uninitialized value, or a value initialized to the exact type, or
something else. It turns out (from reading the source) that you have to
pass in an initialized value, but you can use any type to which the
property's actual type can be transformed.
So, let's document this.
The code section guarded with toggle_refs_mutex includes a call to
g_object_unref(), which may call toggle_refs_notify(). As the latter
tries to acquire the same mutex, glib locks up.
https://bugzilla.gnome.org/show_bug.cgi?id=632884
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
The gdatasetprivate.h header includes gatomic.h directly. It all works
well in GLib, but inside GObject it will trigger the single inclusion
guard.
Since this is a private header, and it's kind of a special case, one way
to fix it is to declare GLIB_COMPILATION around it and fool the single
inclusion guard in gatomic.h into thinking we're compiling GLib and not
GObject.
g_object_notify_by_pspec() will emit the "notify" signal on the given
pspec, short-circuiting the hash table lookup needed by
g_object_notify(). The suggested and documented way of using
g_object_notify_by_pspec() is similar to the way of emitting signals
with their ID.
Emission tests (with no handler attached to the notify signal) show a
10-15% speedup over using g_object_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=615425
This adds static markers and systemtap tapsets for:
* type creation
* object lifetimes (creation, ref, unref, dispose, finalize)
* signal creation and emission
Signal emissions and finalization marker have a corresponding
*_end (or *-end in dtrace) version that is when the corresponding
operation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
The reason we need to enforce this is that the GTypeValueTable
documentation explicitly states that memory is memset to 0 when the
value_init function is called.
https://bugzilla.gnome.org/show_bug.cgi?id=603590
This works around the need to take a custom mutex twice and add the
object to a GSList of objects that are currently in construction for the
common case. Only when the constructor is overwritten do we use the
previous behavior and allow things like singleton objects.
The only slightly incompatible change is that previously, it was ok to
call g_object_set() on construct-only properties while the object was
initialized. This will now fail. If that behavior is needed, setting a
custom constructor that just chains up will reenable this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=557151
Store whether the object has a toggleref before decrementing the
refcount to prevent race condition when two threads simultaneously
try to unref an object with a refcount of 2.
Patch by Antoine Tremblay.
https://bugzilla.gnome.org/show_bug.cgi?id=551706
This avoids a bunch of code and makes construction of simple objects
faster.
Object construction performance improvement:
Non-Threaded Threaded
Simple: 14% 5%
Complex: -1.1% -2.2%
Other tests stable.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
If the class has no properties there could be no notification anyway.
This is an important optimization for construction of simple objects.
Object construction performance improvement:
Non-Threaded Threaded
Simple: 84% 91%
Complex: -1.4% -0.6%
Other tests stable.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
GLib users buildable with gcc 4.4. Patch by Jakub Jelinek.
* glib/gatomic.[hc]: Add G_GNUC_MAY_ALIAS to pointer arguments,
fix macro versions to only operate on objects of the same size.
* glib/gdataset.c:
* glib/gthread.[hc]:
* glib/gdatasetprivate.h: Remove unnecessary casts in
g_atomic_pointer_get calls.
svn path=/trunk/; revision=7875
2009-01-02 Behdad Esfahbod <behdad@gnome.org>
Bug 565136 – Gobject's "notify" signal parameters are wrong in gtk-doc
Patch from Andrzej Zaborowski
* gobject.c (g_object_do_class_init): Fix param order in docs.
svn path=/trunk/; revision=7759
2008-06-29 Björn Lindqvist <bjourne@gmail.com>
Bug 539626 – Update docstrings for g_object_freeze_notify and
g_object_thaw_notify
* gobject/gobject.c: Explain how the freeze count works.
svn path=/trunk/; revision=7102
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: remove trailing whitespace from newly added gtk-doc
comments and reformatted some where they contained overly long or
ill-formatted lines.
svn path=/trunk/; revision=7090
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: moved includes back to the top of the files (before gtk-doc
SECTION comments). Add "config.h" in all files and move system
included before glib includes. Remove trailing whitespace from
SECTION comments and did some reformatting where lines were overly
long, no documentation content was changed.
svn path=/trunk/; revision=7089
Tue Apr 3 12:34:14 2007 Tim Janik <timj@gtk.org>
* gobject.[hc]: invoke GObjectClass.constructed() only for newly
constructed objects, and invoke it while the notify queue is
still being frozen, after all CONSTRUCT* properties have been
set and before random other properties are being set.
* applied modified patch from Ryan Lortie to implement
GObjectClass.constructed() to fix#425324.
2007-04-02 Ryan Lortie <desrt@desrt.ca>
* gobject/gobject.h: Add 'constructed' vcall to GObjectClass.
* gobject/gobject.c (g_object_newv): call ->constructed() as last
step of object construction.
svn path=/trunk/; revision=5441
Tue Aug 29 13:27:33 2006 Tim Janik <timj@gtk.org>
* glib-mkenums.in: fixed to print usage and version info on STDOUT
(#322502).
* gobject.c (g_initially_unowned_init): restore ; after G_DEFINE_TYPE.
Wed Aug 23 10:35:32 2006 Tim Janik <timj@gtk.org>
* gobject.[hc]: changed return value of g_value_dup_object(), fixes#343292.
2006-08-23 Sven Neumann <sven@gimp.org>
* gobject/glib-genmarshal.[c1]: added new command-line option
"--internal" that can be used to let glib-genmarshal generate
internal functions using the G_GNUC_INTERNAL attribute (bug #346647).
Wed Aug 16 13:55:08 2006 Tim Janik <timj@imendio.com>
* gobject.c: conditionally thaw the notify queue after construction,
so we don't trigger warnings when trying to thaw an unfrozen singleton.
Tue Mar 7 17:09:07 2006 Tim Janik <timj@gtk.org>
* gobject.c (g_object_compat_control): added case3 to hand out the
original floating flag handler. required by gtk+ >= 2.10.
Thu Dec 22 14:59:24 2005 Tim Janik <timj@imendio.com>
* gvaluetypes.[hc]: implemented G_TYPE_GTPYE. applied patch
from matthias which implements GType accessors for GValue.
* gparamspecs.[hc]: applied patch from matthias which
implements G_TYPE_PARAM_GTYPE.
* gobject.[hc]:
GUnowned: introduced a new object type that has an initially
floating reference.
g_object_compat_control(): allow setting of a floating flag handler.
Wed Nov 23 18:01:46 2005 Tim Janik <timj@imendio.com>
* gobject.[hc]: added floating reference count.
g_object_is_floating():
g_object_ref_sink(): new functions to deal with floating references.
g_object_force_floating(): new funciton for object implementations
to set the floating flag.
* gobject.c (g_object_init): make objects initially floating.
Wed Nov 23 17:58:13 2005 Tim Janik <timj@gtk.org>
* gparam.[hc]: added g_param_spec_ref_sink().
Mon Aug 1 23:00:42 2005 Tim Janik <timj@imendio.com>
* gclosure.c: turned all modifications to the first 32 integer bits in a
closure into atomic accesses. wrapped write accesses into special macros
to keep the atomic modification logic in a single place. comment cleanups.
* gclosure.h: made all atomicly accessed closure fields volatile.
* gobject.h: made ref_count field volatile.
Sun Jul 31 02:04:23 2005 Tim Janik <timj@gtk.org>
* gobject.c: use g_datalist_set_flags() and g_datalist_unset_flags() to
allow proper locking around &qdata modifications.
Sat Jul 30 21:10:26 2005 Tim Janik <timj@gtk.org>
* gobject.c: reverted notify_mutex introduction, since this prevents
parallelized setting of object properties on different objects, and
serves no apparent purpose (to me at least).
g_object_real_dispose(): removed non-atomic reference count
modifications.
g_object_unref(): make sure the closures array is destroyed when
destroying signal handlers.
* gparam.c: cosmetic changes.
* gsignal.c: comment fixup. allow 16bit blocking count.
* gsignal.c: reverted GClosure related changes.
* gclosure.c: reverted premature commit of atomic reference
counting attempt.
2005-07-15 Matthias Clasen <mclasen@redhat.com>
Make refcounting threadsafe by using atomic
operations. (#166020, Wim Taymans)
* gobject.c: Use a recursive lock to protect the
notify queue.
(g_object_unref): Get rid of g_object_last_unref and
do the last unref handling in g_object_unref.
(g_object_ref, g_object_unref): Use atomic operations.
* gsignal.c (struct _HandlerMatch): Use a full integer
for the ref_count field.
(handler_ref, handler_unref_R): Use atomic operations.
* gparam.c (g_param_spec_ref, g_param_spec_unref):
Use atomic operations instead of a lock to make the
refcounting threadsafe.
* gclosure.c (g_closure_ref, g_closure_unref): Use atomic
operations. This is more complicated here, since the
refcount is stored in a bitfield, so we also have
to access all other bitfield members atomically.
* gsignal.c (handlers_find): Read the meta_marshal flag
of the closure atomically.
* tests/Makefile.am (SUBDIRS): Add tests/refcount
* configure.in: Add tests/refcount
* tests/refcount/properties.c: Test property changes
from multiple threads.
* tests/refcount/signals.c: Test signal emission from
multiple threads.
* tests/refcount/objects.c: Test refcounting from
multiple threads.
* tests/refcount/objects2.c:
* tests/refcount/properties2.c: Tests to measure the
overhead of threadsafe refcounting.
* glib/giochannel.c (g_io_channel_ref, g_io_channel_unref):
Use atomic operations to make refcounting
threadsafe. (#166020, Wim Taymans)
2005-05-05 Owen Taylor <otaylor@redhat.com>
* gobject.[ch] gobject.symbols: Add
g_object_add/remove_toggle_ref() functions to get notification
when a reference count is the last remaining reference; this
enables better memory management for language bindings.
(http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html)
2005-05-05 Owen Taylor <otaylor@redhat.com>
* glib/gdataset.[ch] glib/gdatasetprivate.h: Add
g_datalist_set/unset_flags(), g_datalist_get_flags() functions
to squeeze some bits into a GDataSet... this is needed for
efficient implementation of toggle references in GObject.
* tests/gobject/references.c tests/gobject/Makefile.am:
Add a test case for weak and toggle references.
* glib/gfileutils.[ch]: Rename g_file_replace() back
to g_file_set_contents().
* glib/glib.symbols: Update.
2005-05-05 Owen Taylor <otaylor@redhat.com>
* glib/Makefile.am glib/glib-sections.txt gobject/gobject-sections.txt:
Update
* gobject/tmpl/objects.sgml: Document toggle-references.
2005-03-14 Matthias Clasen <mclasen@redhat.com>
* abicheck.sh: Make work again.
* gsourceclosure.c: Fix a typo.
Make PLT-reduction work with gcc4, and don't include
everything in gobjectalias.h:
* gobject.symbols: Group symbols by header and source
file.
* makegobjectalias.pl: Protect definitions by the same
preprocessor symbols used to guard the headers. Move
the alias declarations to a separate file which is
produced when calling makegalias.pl -def
* Makefile.am (gobjectaliasdef.c): Add a rule to
build this file.
* *.c: Include gobjectalias.h after the other i
GLib headers, include gobjectaliasdef.c at the bottom.
2004-09-16 Matthias Clasen <mclasen@redhat.com>
Implement the same PLT reduction technique used in GTK+:
* Makefile.am: Generate gobjectalias.h from gobject.symbols.
(BUILT_SOURCES): Add gobjectalias.h.
* makegobjectalias.pl: Script to generate gobjectalias.h.
* *.c: Include gobjectalias.h
Sat Nov 29 14:57:20 2003 Tim Janik <timj@gtk.org>
* gobject.c: fix g_object_set() whithin _init() implementations
not working for construct-only properties.
(g_object_init): make the object enter a construct_objects list.
(g_object_newv): remove object from construct_objects after creation.
(g_object_set_valist):
(g_object_set_property): allow construct-only properties for
objects which are in construct_objects.
Thu Nov 27 17:53:52 2003 Tim Janik <timj@gtk.org>
* gtype.[hc]:
(g_type_class_peek_static): variant of class_peek() which works for
static types only.
* gobject.c:
(g_object_do_class_init): make ::notify a run-action signal.
(g_object_newv): use g_type_class_peek_static() by default to
speed up common code path (trades two write-locks for one read-lock).
(g_object_disconnect):
(g_object_connect): allow signal specification words to be
seperated by '-'.
(g_object_set_valist):
(g_object_new_valist): don't leak values.
(g_object_get_property): check property for readability.
(g_object_set_property): check property for writability and to
not be construct-only.
(g_object_set_valist): check property to not be construct-only.
Tue Oct 14 17:40:19 2003 Owen Taylor <otaylor@redhat.com>
* gparamspecs.[ch]: Add a new GParamSpecOverride type
that is a pointer to a different paramspec in a parent
class or interface.
* gparam.[ch]: Add g_paramspec_get_redirect_target()
which follows GParamSpecOverride to the real property.
Make g_param_spec_pool_list() hand redirections,
properties on interfaces.
* gobject.[ch] gobjectnotifyqueue.c: Add
g_object_interface_install_property,
g_object_interface_find_property,
g_object_interface_list_properties(). Redirect virtually all
publically exposed GParamSpec's to the redirect target if
any. (->constructor is the exception.)
(#105894)
2003-09-12 Matthias Clasen <maclas@gmx.de>
Make the g_value_set_x_take_ownership() functions "official"
part of the API (#100948):
* gvaluetypes.[hc]: Add g_value_take_string() (synonym to the
now deprecated g_value_set_string_take_ownership()).
* gparam.[hc]: Add g_value_take_param() (synonym to the
now deprecated g_value_set_param_take_ownership()).
* gobject.[hc]: Add g_value_take_object() (synonym to the
now deprecated g_value_set_object_take_ownership()).
* gboxed.[hc]: Add g_value_take_boxed() (synonym to the
now deprecated g_value_set_boxed_take_ownership()).
* gobject/gobject-sections.txt: Add new g_value_take_x() functions.
* gobject/tmpl/param_value_types.sgml: Document new g_value_take_x()
functions. (#100948)
