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.
