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
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
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.
41e5ba86a7 introduced some changes to the
property flags of GAction. These changes were not a reflection of the
actual interface of GAction but were necessary due to GObject being
overly-sensitive to flag changes on property overrides.
Now that the GObject bug is fixed, we can restore the GAction flags to
their correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
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
There are some races in the condition variable emulation code for
Windows XP with respect to timeouts while waiting.
First, in the event of a timeout, we never remove the waiter from the
condition variable. This can cause crashes later. That problem was
found by Rodrigo Rivas Costa.
Second, if the waiting thread times out and exits just as we were about
to call SetEvent() on its waiter event, we could end up trying to access
the waiter after it was closed/freed. We need to hold on to the lock a
little bit longer to ensure that that's not possible.
https://bugzilla.gnome.org/show_bug.cgi?id=666551
It happens that one wants to customize settings for plugins or
shell extensions, that installing schemas in nonstandard locations.
This patch adds the --schemadir option to gsettings, and ensure
that the appropriate schema is found.
https://bugzilla.gnome.org/show_bug.cgi?id=666415
This interfaceifies the extra functions that were on GDBusActionGroup
for dealing with platform data.
The two main benefits of doing this:
- no longer have to do a silly song and dance in GApplication to avoid
calling GDBusActionGroup API from non-dbus-aware code
- the interface can be reused by the action group exporter to avoid
ugly and unbindable hook callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Now that we're a GActionMap the story about propagating signals from our
(now-constant) internal action group is vastly simplified. If someone
calls g_application_set_action_group() then signals will stop working --
but this function is deprecated and they never worked before, so no big
loss there.
https://bugzilla.gnome.org/show_bug.cgi?id=643736
We provide a mechanism by which a 'platform' (eg: Gtk) can register some
hook functions to be called to collect platform-data at the point of
sending an outgoing action activation request and also to inform the
platform of this data on incoming requests (before and after dispatching
the actual request).
This can be used for forwarding timestamp and startup-notification
information (as is presently done in GApplication) but the before/after
hook could also be used for acquiring/releasing the Gdk lock or other
similar things.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
g_queue_free_full(), to free a Queue including its dynamically-allocated elements.
On similar lines to List and Slist.
void g_queue_free_full (GQueue *queue, GDestroyNotify free_func);
Test case covering g_queue_free_full() is added.
Added export symbol to glib.symbols.
Closes Bug: https://bugzilla.gnome.org/show_bug.cgi?id=657433
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Various places in the code were assuming that the hash table was always
available. Fix this, and also avoid leaking strings now that the hash
table may be NULL.
Based on a patch by Simon McVittie, bug 666167
foo_free is conceptually "worth" one unref; not decrementing the
refcount here means the GArray or GPtrArray wrapper (but not its
contents) would leak in the following call sequence:
p = g_ptr_array_new ();
g_ptr_array_ref (p);
g_ptr_array_free (p, TRUE);
g_ptr_array_unref (p);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Depending how the array is freed, we may want to free the underlying
array (the "segment"), the struct wrapper or both.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
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.
