Commit Graph

401 Commits

Author SHA1 Message Date
Matthias Clasen
23e37e05d2 Small optimization for g_object_set
We've already followed the redirection, no need
to check for that again - just avoid notifying
non-readable properties.
2021-09-20 08:21:42 -04:00
Marco Trevisan (Treviño)
a7262d6357 gobject: Cleanup weak locations data as part of dispose
Weak locations were not fully cleaned on run_dispose() and after dispose
vfunc was called, so ensure that this is the case.

Fixes: #865
2021-09-17 12:28:01 +02:00
Marco Trevisan (Treviño)
e861f60dcb gobject: Cleanup weak locations when the last one has been removed
As per the previous change, an object that had weak locations set may
need to lock again the weak locations mutex during qdata cleanup, but
we can avoid this when we know we're removing the last location, by
removing the qdata entry and freeing the data.

In case a new location is needed for the same object, new data will be
added.

However, by doing this the weak locations during dispose may be
invalidated once the weak locations lock is passed, so check again if
this is the case while removing them.
2021-09-17 12:27:59 +02:00
Marco Trevisan (Treviño)
ea68b22135 gobject: Cleanup GWeakRef locations on object finalization
It can happen that a GWeakRef is added to an object while it's disposing
(or even during finalizing) and this may happen in a thread that (weak)
references an object while the disposal isn't completed yet or when
using toggle references and switching to GWeakRef on notification (as
the API suggests).

In such scenario the weak locations are not cleaned up when the object
is finalized, and will point to a free'd area.

So, during finalization and when we're sure that the object will be
destroyed for sure, check again if there are new weak locations and
unset them if any as part of the qdata destruction.
Do this adding a new utility function so that we can avoid duplicating
code to free the weak locations.

Added various tests simulating this case.

Fixes: #2390
2021-09-17 12:21:23 +02:00
Emmanuele Bassi
6fe0f98360 Add a (diagnostic) warning for finalized floating objects
GTK currently checks if a GtkWidget is finalized while still using a
floating reference—i.e. a widget was disposed without any parent
container owning it.

This warning can be useful to identify and trace ownership transfer
issues in libraries using initially unowned floating object types.

To avoid introducing constraints ex post, we can gate this check behind
both the G_ENABLE_DEBUG compile time flag for GLib, and behind the
G_ENABLE_DIAGNOSTIC environment variable run time check.

Fixes: #2489
2021-09-14 16:09:22 +01:00
Emmanuele Bassi
f62622fc7b docs: Start stanzas with a single paragraph
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.

The documentation is assumed to be in Markdown format, which means:

 - paragraphs must be separated by newlines
 - lines that have an indentation of four or more spaces are considered
   code blocks
 - lines that start with a `#` are considered titles

This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.

See issue: #2365
2021-08-02 13:22:23 +01:00
Allison Ryan Lortie
3764c6730e GObject: add g_object_take_ref()
This works in the same way as g_variant_take_ref(), and for the same
reason.

Updated and Rebased by Nitin Wartkar <nitinwartkar58@gmail.com>

Closes #1112
2021-06-11 18:13:34 +05:30
Jasper St. Pierre
edb40c7171 gobject: Allow passing %NULL for @data in g_object_remove_toggle_ref
gjs has some situations where it's not always aware of the @data that
was passed into g_object_add_toggle_ref, so allow passing %NULL to
just match on @notify.

Rebased and updated by Nitin Wartkar

Closes #817
2021-05-27 21:09:45 +05:30
Emmanuele Bassi
e97ebfe628 Fix the transfer annotations for GClosure constructors
The GClosure constructors in GObject return an instance with a floating
reference.

Fixes: #2299
2021-01-19 11:36:01 +02:00
Sebastian Dröge
a2de4b2479 Clarify in g_object_weak_ref() docs that the callback is called during disposing and not finalizing
This especially has the effect that any GWeakRefs to the object will not
necessarily be set to NULL yet if called as part of
g_object_run_dispose() and not as part of g_object_unref().
2020-12-08 18:09:50 +02:00
Philip Withnall
77361ef45e Merge branch 'fix_extra_warnings' into 'master'
Fix more warnings

See merge request GNOME/glib!1765
2020-11-24 15:37:21 +00:00
Emmanuel Fleury
236d6281b8 Fix signedness warnings in gobject/gobject.c:g_object_new_internal()
gobject/gobject.c: In function ‘g_object_new_internal’:
gobject/gobject.c:1962:25: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1962 |           for (j = 0; j < n_params; j++)
      |                         ^
gobject/gobject.c:1989:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1989 |       for (i = 0; i < n_params; i++)
      |                     ^
2020-11-24 16:17:46 +01:00
Emmanuel Fleury
7753a0492b Fix signedness warnings in gobject/gobject.c:g_object_new_with_custom_constructor()
gobject/gobject.c: In function ‘g_object_new_with_custom_constructor’:
gobject/gobject.c:1836:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1836 |       for (j = 0; j < n_params; j++)
      |                     ^
gobject/gobject.c:1914:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1914 |   for (i = 0; i < n_params; i++)
      |                 ^
2020-11-24 16:17:46 +01:00
Emmanuel Fleury
d50d2098b5 Fix signedness warning in gobject/gobject.c:g_object_class_install_properties()
gobject/gobject.c: In function ‘g_object_class_install_properties’:
gobject/gobject.c:766:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
  766 |   for (i = 1; i < n_pspecs; i++)
      |                 ^
2020-11-24 16:17:46 +01:00
Philip Withnall
9f041c9e05 Merge branch 'th/gobject-new-parameter-list' into 'master'
gobject: allocate parameter list for g_object_new_valist() entirely on stack

See merge request GNOME/glib!1385
2020-11-21 22:55:55 +00:00
Philip Withnall
08d04d0428 gobject: Drop unnecessary volatile qualifiers from internal variables
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #600
2020-11-20 14:40:19 +00:00
Thomas Haller
fb3977e9b4 gobject: limit required stack by heap allocating parameter list in g_object_new_valist()
The previous code consumed a larger additional amount of stack space.
That is because it would allocate the temporary buffer for GValues on
the stack with "g_newa (GValue, 1)" and thus the required stack
space grew with the number of arguments. Granted, this is already
a variadic C function, so the caller already placed that many elements
on the stack. For example, on the stack there are the property names
and the pointers to the arguments, which should amount to roughly
O(n_args * 16) (on 64 bit, with pointers being 8 bytes large).

That is not bad, because it means in the previous version the stack space
would grow linear with the already used stack space. However, a GValue is
an additional 24 bytes (on 64 bit), which probably more than doubles the
required stack space. Let's avoid that, by allocating the temporary list
on the heap after a certain threshold. This probably more than doubles the
number of possible arguments before the stack overflows.

Also, previously the heap allocated "params" array only grew one element
per iteration. Of course, it is likely that libc anyway reallocates
the buffers by growing the space exponentially. So realloc(ptr, 1)
probably does not O() scale worse than doubling the buffer sizes ourselves.
However, it seems clearer to keep track of the allocated sizes ourself, and
only call realloc() when we determine that we are out of space.
Especially because we need to update the value pointers on reallocation.

Note that we now require a heap allocation both for the "params" and the
"values" list. Theoretically that could be combined by using one buffer
for both. But that would make the code more complicated.

Now we pre-allocate buffers for 16 elements on the stack. That
is (16 * (16 + 24) bytes (or 640 bytes) on the stack. I think that
is still acceptable.
2020-11-18 15:26:14 +01:00
Thomas Haller
355c99a077 object: use guint type for n_params argument of g_object_new_is_valid_property()
Two out of three callers pass the count argument from a variable
of type guint. And the third is currently an always positive gint.

We should use the correct integer type that matches the type as it
used otherwise.
2020-11-18 13:38:53 +01:00
Philip Withnall
4f2b1e250d gobject: Standardise on the term ‘instantiatable’
Rather than using a mixture of ‘instantiable’ and ‘instantiatable’
everywhere, standardise on the term which is already in the public API.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2020-11-02 17:22:01 +00:00
Philip Withnall
41937c3631 gobject: Document that g_object_new() zeros out private data
It’s already mentioned at
https://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation,
but is important enough that mentioning it in the documentation for
`g_object_new()` seems helpful.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1022
2020-07-27 01:57:57 +01:00
Philip Withnall
a63efa4291 tree: Fix various ableist language
In almost all cases, rewording the documentation/comments made things
more specific and a little clearer.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1544#note_846645
2020-06-23 10:49:44 +01:00
Philip Withnall
00bfb3ab44 tree: Fix various typos and outdated terminology
This was mostly machine generated with the following command:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).

Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.

There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.

If I’ve missed anything, please file an issue!

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-06-12 15:01:08 +01:00
Edward Hervey
898baa07b1 gobject: Handle runtime checks as such
The various `g_strdup_printf()` returns values in the implementations of GValue
lcopy_func are runtime checks which could be disabled if one wants and therefore
should be handled as such with g_return_val_if_fail()
2020-05-20 17:37:46 +02:00
Philip Withnall
641bbd0848 gobject: Clarify assertion failure on ref-after-finalize
Rename the variables involved so that people get a slightly more
obvious critical warning when they try to ref an object which has
already been finalised.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-03-23 11:48:22 +00:00
Philip Withnall
2474c65037 docs: Clarify handling of 64-bit integer literals with g_object_new()
As with `g_variant_new()` (or any varargs function which takes integer
literals of differing widths), callers need to be careful to ensure
their integer literals have the right width.

Tweak the documentation for `g_object_new()`, `g_object_set()` and
`g_object_get()` to clarify this. The documentation for `g_object_get()`
shows that it is not subject to the same caveats, since it operates on
pointers.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Closes: #833
2019-12-17 12:23:19 +00:00
Alexander Larsson
5afd574e91 Use the GObject hole on 64bit arches for some flags to improve performance
This uses a 32bit hole in the GObject structure on 64bit arches
as a flag field which can be optionally used for some preformance hints.

Currently there is a flag that gets set any time you connect to a signal
on a GObject which is used as early bailout for signal emissions, and using
the flags field instead of a user-data for checking if a GObject is
under construction.
2019-09-02 15:48:32 +02:00
Дилян Палаузов
512655aa12 minor typos in the documentation (a/an) 2019-08-24 19:14:05 +00:00
Philip Withnall
c178c9734c Merge branch 'static_analysis_2_40_patches' into 'master'
Static analysis 2 40 patches

Closes #905

See merge request GNOME/glib!1042
2019-08-24 14:22:38 +00:00
Colin Walters
7b0139b9f4 gobject/gobject.c: Tweak conditional to pacify static analysis
It can't easily see that value is always non-NULL here;
this equivalent tweak will show that it is.
2019-08-24 15:55:49 +02:00
Simon McVittie
41d31cd4b7 g_object_get_property: Document accepting G_VALUE_INIT as new API
Code intended to be portable to older versions of GLib cannot rely
on this being considered valid.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-08-01 09:29:52 +01:00
Simon McVittie
bf8b669061 g_object_get_property: Clarify meaning of G_TYPE_INVALID
"Uninitialized value" is partially correct, since it has not been
initialized with a type, but it's more precise to say
"zero-initialized value". It is still a programming error to pass a
pointer to uninitialized memory with arbitrary contents as the value.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-08-01 09:29:52 +01:00
Christian Hergert
2a4b5caac2 gobject: remove use of generic marshaller from GObject
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.

Related to GNOME/Initiatives#10
2019-06-17 16:13:53 -07:00
Philip Withnall
fa5996927f Merge branch 'drop-g-disable-deprecated' into 'master'
Drop G_DISABLE_DEPRECATED

Closes #1060 and #638

See merge request GNOME/glib!871
2019-06-14 11:24:25 +00:00
Sebastian Dröge
db27933236 Merge branch 'docs-typo-fix' into 'master'
gobject: Fix apostrophe usage in a few small bits of documentation

See merge request GNOME/glib!853
2019-06-11 11:21:52 +00:00
Emmanuele Bassi
56a56f1ee5 Allow calling get_property() with an uninitialized GValue
We already have the GType with which the GValue should be initialized,
so requiring an initialized GValue is not really necessary, and it
actually complicates code that wraps GObject, by requiring the retrieval
of the GParamSpec in order to get the property type. Additionally, it
introduces a mostly unnecessary g_value_reset().

We already changed g_object_getv() to allow passing uninitialized
GValues, but this fell through the cracks.

Closes: #737
2019-06-04 20:05:24 +01:00
Philip Withnall
40ff475977 Annotate various types and macros as deprecated
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.

This is based on the list of deprecations from the reverted commit
80fcb1bc2.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #638
2019-05-30 10:39:11 +01:00
Emmanuele Bassi
8b2f6a5523 Please don't use GInitiallyUnowned and floating refs
This place is not a place of honor… No highly esteemed API is implemented
here… Nothing valued is here.
2019-05-21 11:34:04 +01:00
Emmanuele Bassi
a734a92408 Document the best practice for binding InitiallyUnowned
Right now, the documentation is less than explicit on how language
bindings should handle GInitiallyUnowned.
2019-05-21 11:34:04 +01:00
Philip Withnall
f093ef6a6f gobject: Fix apostrophe usage in a few small bits of documentation
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-05-17 17:39:40 +01:00
Philip Withnall
38de3e9dc3 docs: Use ‘look up’ as a verb, rather than the noun ‘lookup’
Another niggle fixed.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-04-26 12:12:31 +01:00
Philip Withnall
3d3ca9f1fe gobject: Fix various compiler warnings when compiling with G_DISABLE_ASSERT
Mostly unused variables which are only used in a g_assert() call
otherwise.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1708
2019-03-08 19:46:21 +00:00
Philip Withnall
2a570dc5af gobject: Mention quark memory usage for g_object_set_data()
g_object_set_data() should only ever be used with a small, bounded set
of keys, or the memory usage of the quark lookup table will grow
unbounded. Document that.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #682
2019-03-07 10:56:47 +00:00
Tomasz Miąsko
c4cb27d844 gobject: Use atomic operations to read object reference count 2019-02-22 18:09:32 +01:00
Tomasz Miąsko
d72192f69b gobject: Remove unsynchronized read of freeze_count
There is no need to preserve the check, since check is performed again
while holding the notify_locks that protects freeze_count.
2019-02-22 17:51:48 +01:00
Colin Walters
4631cd892d gobject: Change assertions to read values via atomics
I'm trying to use `-fsanitize=thread` for OSTree, and some of
these issues seem to go into GLib.  Also, the sanitizers work better if
the userspace libraries are built with them too.

This fix is similar to
b6814bb37c

Mixing atomic and non-atomic reads trips TSAN, so let's change the
assertions to operate on the local values returned from atomic
read/writes.

Without this change I couldn't even *build* GLib with TSAN, since we
use gresources during compilation, which uses GSubprocess, which hits
this code.

(Minor review fixes made by Philip Withnall <withnall@endlessm.com>.)

https://gitlab.gnome.org/GNOME/glib/issues/1224
2019-01-31 13:18:40 +00:00
Philip Withnall
b9a8c03915 gobject: Convert a debug check from an assertion to a g_critical()
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://gitlab.gnome.org/GNOME/glib/issues/179
2018-10-11 11:40:12 +13:00
Philip Withnall
59a23bf24d gclosure: Minor documentation formatting improvements
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-08-16 10:59:45 +01:00
Philip Withnall
2500dfe3b3 docs: Fix a documentation link
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-07-30 21:15:57 +01:00
Iain Lane
2aacef39b1 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-12 08:47:40 +01:00
Emmanuele Bassi
d3881bb1bf Revert "Merge branch 'type-safe-g-clear-pointer-1425' into 'master'"
This reverts merge request !165
2018-07-11 21:52:31 +00:00
Iain Lane
747c2f5720 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-11 10:52:53 +01:00
Daniel Boles
042ab215b2 GObject: Clarify 8db5542803 by avoiding double -ve
Make the wording easier to understand by saying what we do, rather than
what we avoid doing if the relevant thing did not happen!
2018-04-22 15:03:03 +01:00
Tomasz Miąsko
a9ad793506 gobject: Mark g_object_new_with_properties as non-introspectable
There is no transfer annotation that can express transfer semantics of
g_object_new_with_properties in general. When GInitiallyUnowned object
is constructed the introspection data will be incorrect.

Mark it with skip annotation.

https://bugzilla.gnome.org/show_bug.cgi?id=795025
2018-04-10 12:57:19 +01:00
Daniel Boles
8db5542803 GObject: Elaborate notify emission timing, options
We only said receiving ::notify doesn’t always guarantee that anything
actually changed, but we didn’t explain how we can get that guarantee.

https://bugzilla.gnome.org/show_bug.cgi?id=795096
2018-04-09 13:56:01 +01:00
Philip Withnall
809c66639f gobject: Mention transfer semantics of installing properties on GObjects
GParamSpec supports floating references.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
2018-02-14 15:11:11 +00:00
Philip Withnall
88101e5981 docs: Add missing apostrophes in GObject documentation
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
2018-01-15 15:35:45 +00:00
Christian Hergert
3fae39a5d7 gobject: add type propagation to gobject ref API
Currently, g_object_ref() and g_object_ref_sink() return a
gpointer which can mask issues when assigning to fields or
returning from a function.

To help catch these type of programming errors, we can propagate
the type of the parameter through the function call on GCC
using the typeof() C language extension.

This will cause offending code to have a warning, but will
continue to be source and binary compatible.

This is only enabled when GLIB_VERSION_MAX_ALLOWED is 2.56 or greater.

https://bugzilla.gnome.org/show_bug.cgi?id=790697
2017-12-08 11:14:52 +00:00
Philip Withnall
3eacec1587 Use hash tables as sets in various places
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.

Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=749371
2017-10-26 12:27:17 +01:00
Mikhail Zabaluev
0ea004c6f9 gobject: Skip more non-introspectable data/qdata methods
https://bugzilla.gnome.org/show_bug.cgi?id=756588
2017-09-11 20:34:46 +01:00
Mikhail Zabaluev
1e45c0a0e1 gobject: Add missing (nullable) and (out) annotations on the data/qdata API
https://bugzilla.gnome.org/show_bug.cgi?id=756588
2017-09-11 20:34:45 +01:00
Federico Mena Quintero
51e852e5d0 validate_pspec_to_install(): Factor out function to validate a GParamSpec
This was duplicated also in g_object_interface_install_property().

Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.

https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 12:44:45 -05:00
Federico Mena Quintero
20720eaf1e validate_and_install_property(): Check pspec-specific fields in the same order as g_object_interface_install_property()
https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 12:44:45 -05:00
Federico Mena Quintero
95f44b280f validate_and_install_property(): Validate presence of get/set_property methods last
https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 12:44:45 -05:00
Federico Mena Quintero
1b08414f06 g_object_interface_install_property(): Do interface-specific validations first
https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 12:44:45 -05:00
Federico Mena Quintero
e667d0d4c0 install_property_internal(): Propagate failure when installing duplicated properties
https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 12:44:41 -05:00
Federico Mena Quintero
9dd9fe4feb validate_and_install_class_property(): Factor out function to add a new property to a class
This was duplicated between g_object_class_install_property() and
g_object_class_install_properties().

https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 11:26:01 -05:00
Federico Mena Quintero
85ef144334 GObjectClass: extract class type and parent type at the beginning
https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 11:26:01 -05:00
Federico Mena Quintero
7d9a6c8687 GObjectClass: Validate installing property/properties in the same way
Then we'll be able to factor out duplicated code.

https://bugzilla.gnome.org/show_bug.cgi?id=787551
2017-09-11 11:26:01 -05:00
Sébastien Wilmet
6b948d9613 gobject/: LGPLv2+ -> LGPLv2.1+
All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Mohammed Sadiq
274f336f6a docs: Trivial typo fixes
The presence of space was resulting in wrongly rendered documentation
in devhelp (and probably in other documentations).

https://bugzilla.gnome.org/show_bug.cgi?id=782068
2017-05-16 11:22:54 +01:00
Emmanuele Bassi
f952fdf3fc Drop trailing semi-colon from G_DEFINE_ macro
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.

https://bugzilla.gnome.org/show_bug.cgi?id=669355
2017-04-10 10:38:31 +01:00
Tim-Philipp Müller
a83ccc535f gobject: remove duplicate GType sanity check
This is going to be checked again by g_object_new_with_properties()
and g_object_new_valist() anyway, so might just as well leave it
to those functions to do the check and only do it once. It doesn't
matter which function emits the critical warning in the end either,
as one has to look at a stack trace to find out what code triggered
it in any case.

https://bugzilla.gnome.org/show_bug.cgi?id=780908
2017-04-08 01:20:29 -04:00
Philip Withnall
2f2c2b6362 gobject: Fix Since/Deprecated versions for GParameter replacement API
This slipped through the review cracks.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 11:09:53 +01:00
Fabian Orccon
e2c3b7f634 gobject: Deprecate g_object_newv
g_object_newv uses a GParameter as argument. Since GParameter
is deprecated due to this type is not introspectible,
g_object_newv is deprecated now.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 11:00:23 +01:00
Fabian Orccon
c6d373bfe7 gobject: Add g_object_setv and g_object_getv functions
https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 10:38:30 +01:00
Fabian Orccon
26b211ef89 gobject: Add g_object_new_with_properties
g_object_new_with_properties is an alternative to g_object_newv.
The last one, takes an array of GParameter. However, GParameter
is a rarely used type and this type is not introspectible, so
it will not work properly in bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 10:38:30 +01:00
Fabian Orccon
19e81dedc9 gobject: Add helper functions to handle warnings in g_object_new/set/get
g_object_new_is_valid_property
g_object_get_is_valid_property
g_object_set_is_valid_property

https://bugzilla.gnome.org/show_bug.cgi?id=709865
2017-03-31 10:38:30 +01:00
Christian Hergert
18a33f72db introspection: use (nullable) or (optional) instead of (allow-none)
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.

It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
2016-11-22 14:14:37 -08:00
Emmanuele Bassi
5ff8579527 Fix debug builds under MSVC
The C spec leaves conditional evaluation inside a macro expansion as
undefined behaviour. This means we cannot use constructs like:

  GOBJECT_IF_DEBUG(OBJECTS, {
    ...
  #ifdef BLAH
    ...
  #endif
    ...});

Because compilers are entirely justified to ignore the conditional, or,
like in the case of MSVC, error out.

https://bugzilla.gnome.org/show_bug.cgi?id=769504
2016-08-04 10:18:46 +01:00
Kang Hu
42dad59cc1 gobject: add GOBJECT_IF_DEBUG macro for debugging gobjects and gsignals.
historically, DEBUG_CODE(gtype.c) and IF_DEBUG(gobject.c, gsignal.c)
macros are used to support debugging messages about object bookkeeping
and signal emission.
DEBUG_CODE has never been used in gtype.c. IF_DEBUG, when used, must be
accompanied by an extra #ifdef G_ENABLE_DEBUG. this is cumbersome.

this patch add a new macro GOBJECT_IF_DEBUG based on DEBUG_CODE as
a replacement for both DEBUG_CODE and IF_DEBUG.

https://bugzilla.gnome.org/show_bug.cgi?id=729914
2016-07-16 20:54:44 -04:00
Philip Withnall
25a7c817d3 glib: Add missing (nullable) and (optional) annotations
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.

Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.

This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.

https://bugzilla.gnome.org/show_bug.cgi?id=719966
2015-11-07 10:48:32 +01:00
Matthias Clasen
3bd1618ea9 Disable deprecation warnings for the stable release again
Keeping these enabled causes too many people to file
bugs against gobject, and not enough people to send
patches to port away from deprecated properties.
2015-09-14 18:42:12 -04:00
Michael Catanzaro
ee6740aa78 Fix a typo 2015-09-10 20:46:37 -05:00
Matthias Clasen
00933dfc9c Speed up property change notification a bit
Avoid the quark lock and hash table lookup for every
emission of ::notify.
2015-09-07 20:56:10 -04:00
Matthias Clasen
a62ad79f5c Clean up locking in g_object_notify_queue_add
Instaed of returning with the lock held, simply assert
that this cannot happen:

https://bugzilla.gnome.org/show_bug.cgi?id=749678#c4
2015-09-07 19:57:53 -04:00
Philip Withnall
c5cd1c5f02 gobject: Add cross-links from GObject reference docs to tutorials
Add some brief links from the GObject reference documentation to the
existing tutorial and overview sections on GObjects.

https://bugzilla.gnome.org/show_bug.cgi?id=743018
2015-08-19 12:54:50 +01:00
Ryan Lortie
d9de830b65 Convert remaining uses of 'Rename to:'
This was replaced by (rename-to) in 2013 (see bug 676133).

They're also causing gtk-doc trouble, so let's get rid of them.
2015-03-12 16:55:22 -04:00
Philip Withnall
4aedc85fb3 gobject: Mention g_clear_object() in g_object_unref() documentation
https://bugzilla.gnome.org/show_bug.cgi?id=741779
2015-03-03 18:40:33 +00:00
Philip Withnall
1cf7f5a240 gobject: Fix a typo in a documentation comment 2015-01-25 17:09:35 +00:00
Alexander Larsson
b1dd594a22 Remove atomics from g_clear_object/g_clear_pointer
Practically no caller of these functions require atomic behaviour,
but the atomics are much slower than normal operations, which makes
it desirable to get rid of them. We have not done this before because
that would be a break of the ABI.

However, I recently looked into this and it seems that even if the
atomics *are* used for g_clear_* it is not ever safe to use this.  The
atomics protects two threads that are racing to free a global/shared
object from freeing the object twice. However, any *user* of the global
object have no protection from the object being freed while in use,
because there is no paired operation the reads and refs the object
as an atomic unit (nor can such an operation be implemented using
purely atomic ops).

So, since nothing could safely have used the atomic aspects of these
functions I consider it acceptable to just remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=733969
2014-07-30 15:11:01 +02:00
Javier Jardón
60fe7b46d2 docs: Use "Returns:" instead "Return:" 2014-07-10 17:09:30 +01:00
Ryan Lortie
6677906436 GObject: tweak property deprecation warnings
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
2014-06-27 14:44:36 -04:00
Ryan Lortie
d0e7061785 GObject: warn on use of deprecated properties
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
2014-06-24 16:18:30 -04:00
Ryan Lortie
f2f66bfe45 docs: warn about installing properties after init
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
2014-06-06 16:44:47 -04:00
Ryan Lortie
85e9455f68 Revert "GObject: prevent installing properties after init"
This reverts commit ddb0ce1421.

Conflicts:
	gobject/gobject.c

https://bugzilla.gnome.org/show_bug.cgi?id=698614
2014-06-06 16:44:47 -04:00
Ryan Lortie
bbdb2345fc gobject: add 'explicit notify' GParamSpec flag
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
2014-06-06 10:25:48 -04:00
Marek Kasik
6a8c2685be gobject: unref unused class
If g_type_class_ref() returns a class which is not
a GObjectClass we need to unref it before return in
object_interface_check_properties().

https://bugzilla.gnome.org/show_bug.cgi?id=706983
2014-05-22 11:00:14 +02:00
Matthias Clasen
4360756c69 Avoid overeager warning about deprecated properties
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
2014-05-13 08:08:38 -04:00
Dan Winship
5cab3fcec1 gobject: re-allow finalization from constructor()
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
2014-02-15 10:20:53 -05:00
Matthias Clasen
bc6ee788b4 docs: let go of &ast;
Since we are no longer using sgml mode, using /&ast; &ast;/ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
2014-02-14 21:33:36 -05:00
Matthias Clasen
e7fd3de86d Eradicate links and xrefs
These are all replaced by markdown ref links.
2014-02-08 12:26:56 -05:00
Matthias Clasen
5baa0f2af5 Stop using <para> for ids
Instead, use the id support in markdown headings.
2014-02-06 16:48:49 -05:00
Matthias Clasen
3232425785 Docs: replace <literal> by ` 2014-02-06 08:07:16 -05:00
Matthias Clasen
a35d8a4c77 Docs: use quotes instead of firstterm 2014-02-06 08:07:16 -05:00
Matthias Clasen
adf892e96a Annotate all examples with their language
The C ones, at least.
2014-02-01 15:11:49 -05:00
Matthias Clasen
42cf80780b Docs: Big entity cleanup
Strip lots of entity use from |[ ]| examples (which are now
implicit CDATA). Also remove many redundant uses of <!-- -->.
2014-02-01 12:00:30 -05:00
Matthias Clasen
60b623d3fb GObject: Convert docs to markdown
In particular, convert lists to markdown syntax.
2014-02-01 10:22:45 -05:00
Matthias Clasen
17f51583a8 Docs: Convert examples to |[ ]| 2014-01-31 21:56:33 -05:00
Matthias Clasen
c575d24dfb Docs: Don't use the note tag
More markup avoidance.
2014-01-31 18:20:06 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Matthias Clasen
28c2706da7 Drop g_trap_object_ref debugging mechanism
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
2013-12-02 21:48:03 -05:00
Matthias Clasen
429010b15c Document details of GObject::notify
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
2013-11-23 16:44:31 -05:00
Dan Winship
efecfe0fac gobject: simplify object-in-construction handling
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
2013-10-22 11:01:15 -04:00
Dan Winship
0d62eb467f gobject: forbid finalization-during-construction
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
2013-10-22 11:01:15 -04:00
Nick Schermer
4b334ef8f1 gobject: Handle ref_count==0 in notify_by_pspec
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
2013-08-14 18:11:05 +01:00
Ryan Lortie
c1e32a5c59 GObject: turn add-property-after-init to a warning
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
2013-06-10 11:18:06 -04:00
Ryan Lortie
a8a9afe17c GObject: prevent installing properties after init
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
2013-05-29 09:25:25 -04:00
Matthias Clasen
2349635ebe Trivial documentation typos 2013-05-29 08:37:57 -04:00
Dan Winship
4b94c0831e Use 'dumb quotes' rather than `really dumb quotes'
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
2013-05-21 11:23:22 -03:00
Dan Winship
c0e0c6a420 gobject: rename an unused parameter to make AIX happy 2013-05-02 13:58:25 -04:00
Ryan Lortie
7d61da0c07 g_object_new: check for NULL from _constructor()
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
2013-04-26 11:34:27 -04:00
Ryan Lortie
bfa8bef7b9 GObject: substantially rework g_object_new()
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
2013-04-23 14:39:09 -04:00
Ryan Lortie
e8438f98e2 Revert "GObject: prevent installing properties after init"
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.
2013-04-22 18:32:49 -04:00
Ryan Lortie
ddb0ce1421 GObject: prevent installing properties after init
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
2013-04-22 17:40:51 -04:00
Sébastien Wilmet
e569079414 Doc: clarify a bit g_signal_connect_object()
"the object" can be a bit confusing for a beginner, he can think it is
the @instance.

https://bugzilla.gnome.org/show_bug.cgi?id=695887
2013-03-15 09:07:29 +01:00
Kjell Ahlstedt
269f890474 GObject: Fix code snippet in description of floating reference.
https://bugzilla.gnome.org/show_bug.cgi?id=688180
2012-11-21 18:09:46 -05:00
Ryan Lortie
5272bc4d67 Revert "[gobject] set all properties before constructed()"
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
2012-11-19 10:30:47 -05:00
Ryan Lortie
028d4a03f2 [gobject] set all properties before constructed()
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
2012-10-08 11:40:00 -04:00
Ryan Lortie
8fd75705f4 fix g_signal_connect_object() documentation
g_signal_connect_object() now works properly, so we can remove the note
in the docs about it being broken.

https://bugzilla.gnome.org/show_bug.cgi?id=118536
2012-10-08 11:22:04 -04:00
Matthias Clasen
1254ca716b Add an atomic compare-and-exchange operation for object data
This is useful when using object data in thread-safe libraries.

https://bugzilla.gnome.org/show_bug.cgi?id=682849
2012-09-02 15:09:13 -04:00
Philip Withnall
f642209ef4 gobject: Document notify signal deduplication with freeze/thaw
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
2012-05-28 15:47:07 +01:00
Xavier Claessens
00285b7517 Add g_clear_pointer()
Also reimplement g_clear_object() using g_clear_pointer()

https://bugzilla.gnome.org/show_bug.cgi?id=674634
2012-04-27 09:42:29 +02:00
Dan Winship
ab59739e11 gobject: Use a destructor rather than g_atexit() for refcount debugging
https://bugzilla.gnome.org/show_bug.cgi?id=669671
2012-02-15 09:54:38 -05:00
Matthias Clasen
99c166501a Fix parameter name mismatches in GWeakRef api 2012-01-03 10:48:50 -05:00
Ryan Lortie
46c2f570da GWeakRef: add a weak GObject reference believed to be thread-safe
This patch is a joint work with Simon McVittie.

https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:15 -05:00
Simon McVittie
28c87a5594 g_object_weak_ref, g_object_add_weak_pointer: document non-thread-safety
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
2012-01-02 12:23:11 -05:00
Ryan Lortie
557da16507 GObject: do checks on interface property install
Add some checks to g_object_interface_install_property() similar to
those in g_object_class_install_property().

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:45:57 -05:00
Ryan Lortie
b237187109 GObject: require READ or WRITE on property install
g_object_class_install_property() currently lets you install properties
that are neither readable nor writable.  Add a check to prevent that.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:43:21 -05:00
Ryan Lortie
4e793c2eef GObject: allow G_PARAM_CONSTRUCT on any override
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
2011-12-20 19:40:44 -05:00
Ryan Lortie
d8d78688a8 GObject: change the order of property checks
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
2011-12-20 19:18:25 -05:00
Ryan Lortie
5fb7a8e127 GObject: fix property override type checks
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
2011-12-20 19:18:25 -05:00
Ryan Lortie
958f2bac7a GObject: fixup reversed logic in last commit
Accidentally dropped a !.
2011-12-20 15:29:16 -05:00
Ryan Lortie
3af050f6fc gobject: Clean up logic in property checks
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.
2011-12-20 15:12:44 -05:00
Ryan Lortie
af24dbc12a gobject: loosen property override flag restrictions
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
2011-12-20 14:58:38 -05:00
Matthias Clasen
e50d8a11b2 Cosmetic doc change 2011-12-09 08:01:12 -05:00
Nicola Fontana
f24d8247b3 Do not use static GTypeInfo and GInterfaceInfo
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
2011-11-29 22:03:25 -05:00
Matthias Clasen
2da24259ab Fix !debug builds
As pointed out by Chun-wei Fan in bug 664455, parts of the merged
gobjectnotifyqueue.c code ended up inside an #ifdef G_ENABLE_DEBUG
section.
2011-11-22 19:25:03 -05:00
Ryan Lortie
877c0ad5b8 [notify] remove some rather bogus 'inline' use 2011-11-16 17:50:13 +00:00
Ryan Lortie
ac0ddcf23f [notify] dispatch 'notify' directly if not frozen
Avoid the notify queue in the case that we're not already frozen.
2011-11-16 17:50:13 +00:00
Ryan Lortie
39458748dd [notify] add 'conditional' to _notify_queue_freeze
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.
2011-11-16 17:50:13 +00:00