Commit Graph

975 Commits

Author SHA1 Message Date
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
b3b9f82206 GObject: add test for interface property overrides
Add a testcase to check all possibilities for overriding a property
specified on an interface from an implementation of that interface,
changing the type and flags.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:18:26 -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
Ryan Lortie
a2e9318d4a two test fixes for ARM
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.

Second, we have some signed/unsigned woes in the gparam transform tests.
2011-12-14 09:33:30 -05:00
Simon McVittie
29f2ced8eb various GLib tests: plug memory leaks
These don't really matter, since it's test code, but they do obscure
real leaks in the library.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
2011-12-14 12:40:16 +00:00
Stef Walter
7e92997539 documentation fixes
Fixes for gtk-doc warnings.

http://bugzilla.gnome.org/show_bug.cgi?id=66469

https://bugzilla.gnome.org/show_bug.cgi?id=664699
2011-12-13 23:01:51 -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
Stef Walter
fcc69fd318 GBytes: A new type for an immutable set of bytes.
* Represents an immutable reference counted block of memory.
 * This is basically the internal glib GBuffer structure exposed,
   renamed, and with some additional capabilities.
 * The GBytes name comes from python3's immutable 'bytes' type
 * GBytes can be safely used as keys in hash tables, and have
   functions for doing so: g_bytes_hash, g_bytes_equal
 * GByteArray is a mutable form of GBytes, and vice versa. There
   are functions for converting from one to the other efficiently:
   g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
 * Adds g_byte_array_new_take() to support above functions

https://bugzilla.gnome.org/show_bug.cgi?id=663291
2011-11-24 08:58:38 +01: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
Murray Cumming
951827379f gsignal.h: Remove trailing comma 2011-11-18 10:46:35 +01:00
Ryan Lortie
877c0ad5b8 [notify] remove some rather bogus 'inline' use 2011-11-16 17:50:13 +00:00
Ryan Lortie
9253f38a90 [notify] add warning to gobjectnotifyqueue.c
Mention that this file gets installed, so people should probably not
modify it.
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
Ryan Lortie
393d4c28b4 [notify] Remove GObjectNotifyContext indirection
This silly abstraction is causing more trouble than it's worth -- just
use the relevant bits directly.
2011-11-16 17:50:13 +00:00
Ryan Lortie
8215fc5f25 [notify] lift some logic out of _notify_queue_add
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().
2011-11-16 17:50:12 +00:00
Ryan Lortie
760037ec46 [notify] remove an obviously false comment 2011-11-16 17:50:12 +00:00
Ryan Lortie
45d80cf9bd [notify] lift some code outside of critical region 2011-11-16 17:50:12 +00:00
Ryan Lortie
1d98f93194 [notify] drop some unused code 2011-11-16 17:50:12 +00:00
Ryan Lortie
128862eafe [notify] merge gobjectnotifyqueue.c into gobject.c
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.
2011-11-16 17:50:12 +00:00
Ryan Lortie
688059cb94 [notify] remove some useless forward declarations
These cause trouble in the next commit.
2011-11-16 17:50:12 +00:00
Matthias Clasen
599f254066 Cleanups to debug env var handling 2011-11-12 19:13:44 -05:00
Marc-André Lureau
fb95c20c96 Add G_SIGNAL_DEPRECATED
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
2011-11-07 23:12:45 +01:00
Dan Winship
a5bf1c117b Fix g_variant_get_gtype() deprecation message
Instead of:

warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]

show:

warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]

Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
2011-11-07 13:48:30 -05:00
Matthias Clasen
328be3938e GObject: Don't use G_DISABLE_DEPRECATED for functions 2011-11-03 00:09:32 -04:00
Dan Winship
f9c2362e43 glib-mkenums: add --identifier-prefix and --symbol-prefix args
Allow passing --identifier-prefix and --symbol-prefix to glib-mkenums,
with the same meanings as in g-ir-scanner, to allow fixing up the enum
name parsing globally rather than needing to add a /<* *>/ override to
each enum.

https://bugzilla.gnome.org/show_bug.cgi?id=661797
2011-10-28 18:04:28 -04:00
Dan Winship
dd4a8d333d glib-mkenums.in: fix @ENUMPREFIX@ with /*< underscore_name=... >*/
For enums defined with an underscore_name override, @ENUMPREFIX@
would include a trailing "_". Fix.

https://bugzilla.gnome.org/show_bug.cgi?id=661797
2011-10-28 15:44:13 -04:00
Javier Jardón
108480b7ba gobject: Use G_VALUE_INIT 2011-10-18 17:12:33 +01:00
Ryan Lortie
b0ab7aba6b push G_THREADS_MANDATORY over the cliff
This was used as an optimisation for the macro hackery that used to live
in gthread.h.  If a particular library or program knew that it could
rely on thread support being enabled, it would allow for static
evaluation of conditionals in some of those macros.

Since the macros are dead and thread support is now always-on, we can
get rid of this bit of legacy.
2011-10-16 21:59:55 -04:00
Ryan Lortie
b076020719 gobject/gio: some last missed statics/inclues 2011-10-16 21:53:03 -04:00
Ryan Lortie
38e8ecd62a more 'static' adding in testcases
No dead code found this time...
2011-10-16 21:41:15 -04:00
Simon McVittie
5dcc502f91 Document that types are limited to 64 KiB
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=659916
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2011-10-15 17:59:35 -04:00
Giovanni Campagna
96817746d9 Turn GKeyFile into a boxed for introspection
Using the new refcounting API, introduce a boxed type wrapping
GKeyFile and expose it introspection bindings in glib-types.h.
2011-10-15 17:51:25 -04:00
Ryan Lortie
430c5635f2 g_thread_new: never fail
Remove the GError argument from g_thread_new() and abort on failure.
Introduce g_thread_try() for those who want to handle failure.
2011-10-13 01:00:57 -04:00
Ryan Lortie
015f4b4513 thread: nuke the concept of 'joinable'
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().

Change the wording in the docs.  Clarify expectations for
(deprecated) g_thread_create().
2011-10-13 00:43:33 -04:00
Matthias Clasen
daede1dc27 Disable deprecations where appropriate in tests 2011-10-12 00:48:18 -04:00
Chun-wei Fan
08d6e1147d Use GLIB_DEPRECATED instead of G_GNUC_DEPRECATED in our headers
This will let others opt out of seeing GLib deprecation warnings
by defining GLIB_DISABLE_DEPRECATION_WARNINGS.

https://bugzilla.gnome.org/show_bug.cgi?id=661438
2011-10-11 13:42:59 -04:00
Matthias Clasen
93b3f6477e Add G_GNUC_DEPRECATED to deprecated functions in gobject 2011-10-08 23:23:43 -04:00
Chun-wei Fan
49b93a0bba gobjet/gclosure.c: Fix styling issues
...so that it looks more consistent with the rest.
2011-10-06 16:02:18 +08:00
Chun-wei Fan
e80d8f0c23 gobject/gclosure.c: Add type cast for int_val = value
This will silence compiler warnings on Visual C++.

(Sorry for the bad fix just now.)
2011-10-06 15:37:52 +08:00
Chun-wei Fan
d77f65d24d Revert "gobject/gclosure.c: Made up for missed pointer deref"
This reverts commit d792a1ebe4.
2011-10-06 15:33:34 +08:00
Chun-wei Fan
d792a1ebe4 gobject/gclosure.c: Made up for missed pointer deref
The value parameter is a gpointer * (void **), but ffi_arg itself is not a
pointer type, so make up for dereference here.
2011-10-06 15:24:08 +08:00
Dan Williams
8e82225aed closure: fix handling of ENUMs and integral return types on 64-bit BE platforms
enums are stored in v_long but need to be marshalled as signed
integers.  On platforms where int is 32 bits, taking the
address of v_long resulted in the wrong 32 bits being marshalled.
So we need to stuff the enum's int-sized value to a temporary
int-sized variable and marshall that instead.

Second, on return, libffi actually returns a pointer to a value
that's sized according to platform conventions, not according to
what the caller requested.  ie if ffi_type_sint was requested, the
value can still be a 64-bit sign-extended long on a 64-bit
architecture like PPC64, thus the caller cannot simply cast
the return value as a pointer to the desired type, but must cast
as a pointer to an integral type and then cast to the desired
type to remove any sign extension complications.

For more information on how to correctly handle libffi return
values, see the following bug, specifically comment 35:

https://bugzilla.redhat.com/show_bug.cgi?id=736489

"For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
returns full 64-bit values that you can truncate in the calling code.   It's
just the way it is has always been.  Please don't change libffi.  I'll document
this clearly for the next version (perhaps there is a mention of this, I
haven't looked yet).

The same is true for returning 8-bit values, for instance, on 32-bit systems.
All ABIs extend those results to the full 32-bits so you need to provide a
properly aligned buffer that's big enough to hold the result."

https://bugzilla.gnome.org/show_bug.cgi?id=659881
2011-10-05 14:08:22 -05:00