The G_CONST_RETURN define in GLib is, and has always been, a bit fuzzy.
We always used it to conform to the platform, at least for public-facing
API.
At first I assumed it has something to do with brain-damaged compilers
or with weird platforms where const was not really supported; sadly,
it's something much, much worse: it's a define that can be toggled at
compile-time to remove const from the signature of public API. This is a
truly terrifying feature that I assume was added in the past century,
and whose inception clearly had something to do with massive doses of
absynthe and opium — because any other explanation would make the
existence of such a feature even worse than assuming drugs had anything
to do with it.
Anyway, and pleasing the gods, this dubious feature is being
removed/deprecated in GLib; see bug:
https://bugzilla.gnome.org/show_bug.cgi?id=644611
Before deprecation, though, we should just remove its usage from the
whole API. We should especially remove its usage from Cally's internals,
since there it never made sense in the first place.
This adds a wrapper macro to clutter-private that will use
g_object_notify_by_pspec if it's compiled against a version of GLib
that is sufficiently new. Otherwise it will notify by the property
name as before by extracting the name from the pspec. The objects can
then store a static array of GParamSpecs and notify using those as
suggested in the documentation for g_object_notify_by_pspec.
Note that the name of the variable used for storing the array of
GParamSpecs is obj_props instead of properties as used in the
documentation because some places in Clutter uses 'properties' as the
name of a local variable.
Mose of the classes in Clutter have been converted using the script in
the bug report. Some classes have not been modified even though the
script picked them up as described here:
json-generator:
We probably don't want to modify the internal copy of JSON
behaviour-depth:
rectangle:
score:
stage-manager:
These aren't using the separate GParamSpec* variable style.
blur-effect:
win32/device-manager:
Don't actually define any properties even though it has the enum.
box-layout:
flow-layout:
Have some per-child properties that don't work automatically with
the script.
clutter-model:
The script gets confused with ClutterModelIter
stage:
Script gets confused because PROP_USER_RESIZE doesn't match
"user-resizable"
test-layout:
Don't really want to modify the tests
http://bugzilla.clutter-project.org/show_bug.cgi?id=2150
The marshallers we use for the signals are declared in a private header,
and it stands to reason that they should also be hidden in the shared
object by using the common '_' prefix. We are also using some direct
g_cclosure_marshal_* symbol from GLib, instead of consistently use the
clutter_marshal_* symbol.
Add annotations such as (transfer-none) (out) (element-type ClutterActor),
and so forth to the doc comments as appropriate.
The annotations added here are a combination of the annotations previously
in gir-repository for Clutter and annotations found in a review of all
return values with that were being parsed with a transfer of "full".
http://bugzilla.openedhand.com/show_bug.cgi?id=1452
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
The BindingPool constructor should only check for duplicate pools
and then set the :name constructor-only property. If a BindingPool
is created without a name we also make a fuss about it.
It is also possible to simply dispose of a binding pool using
g_object_unref(), as long as it has been created by using
clutter_binding_pool_new() or directly with g_object_new(). Only
BindingPools attached to a class are not owned by the user.
ClutterBindingPool is already "problematic" in terms of memory
management for language bindings and gobject-introspection. It
also lacks a GType.
Turning ClutterBindingPool into a GBoxed would not make much
sense, since it does not adhere to the copy/free semantics. It
could be referenced/unreferenced, but in that case we can just
as well use GObject as a base class instead of reimplemeting
a ref-counted object and then boxing it.
ClutterBindingPool is obviously a terminal class, so we just
hide the instance and class structures.
When removing a binding entry from the binding pool we should not
only remove it from the hash table, but also from the linked list
we use to iterate over inside the block/unblock_action() pair.
The clutter_binding_pool_list_actions() was not implemented. The
utility of a call listing all the action names is also debatable:
all the functions related to the key bindings take the key symbol
and modifiers -- except the block_action() and unblock_action()
pair.
As of now, a key binding installed into a BindingPool is always there
and cannot be changed.
This is problematic for sub-classes trying to override the callback
or the action for a given key binding.
This commit adds the ability to override the closure for an existing
key binding inside a binding pool -- assumed the caller knows the
key symbol and modifiers used to install the key binding in the first
place.
* clutter/Makefile.am:
* clutter/clutter.h: Add ClutterBindingPool to the build.
* clutter/clutter-binding-pool.c:
* clutter/clutter-binding-pool.h: Add ClutterBindingPool, a data
structure meant to hold (key symbol, modifiers) pairs and associate
them to a closure. The ClutterBindingPool can be used to install
key bindings for actors and then execute closures inside the
key-press-event signal handlers, removing the need for big
switch() or if() blocks for each key.
* clutter/clutter-event.c: Consistently use "key symbol" instead
of "key value".
* clutter/clutter-event.h: Add more modifier masks.
* clutter/clutter-marshal.list:
* tests/conform/Makefile.am:
* tests/conform/test-binding-pool.c:
* tests/conform/test-conform-main.c: Add ClutterBindingPool
conformance test.
* tests/interactive/Makefile.am:
* tests/interactive/test-binding-pool.c: Add interactive test (and
example code) for the ClutterBindingPool usage.
