ClutterScript should be able to automatically call gettext() and friends
on strings loaded from a UI definition, prior to passing the string to
the object it is constructing.
The basic implementation is trivial:
- set a translation domain on the ClutterScript instance
- mark the translatable strings inside the JSON data, like:
"property" : {
"translatable" : true,
"string" : "a translatable string"
}
The hard part is now getting the tools we use to extract the
translatable strings to understand the JSON format we use inside
ClutterScript.
GLib has gained support for compiling ancillary data files into the same
binary blob as a library or as an executable.
We should add this feature to ClutterScript, so that it's possible to
bundle UI definitions with an application.
To allow language bindings to properly override Script.connect_signals()
they'll need access access to Script.connect_signals_full().
Thanks to Jeremy Moles for reporting.
A bunch of private functions we use when parsing got exposed accidentaly
to the list of public symbols by virtue of not having the leading '_'
that we use to filter them out of the shared object — all the while the
header that declares them is a private, non installed one.
Let's rectify this situation with a bit of minor surgery on the code.
Do not just allow animating states connected to signals: add a "warp"
optional key that ends up calling clutter_state_warp_to_state(). This
is useful for debugging.
Currently, defining states for object signals can only be done by
defining a ClutterState inside the ClutterScript definition. We should
allow creating a (named) ClutterState in code, and associating it to a
ClutterScript instance — and have the Script resolve the "state" field
of a signal definition correctly.
One of the uses of a ClutterState state machine along with ClutterScript
is to provide a quick way to transition from state to state in response
to signal emitted on specific instances.
Connecting a real function, in code, to a specific signal does not
improve the ease of use of ClutterScript to define scenes.
By adding a new signal definition to the current one we can have both a
simple way to define application logic in code and in the UI definition
file.
The new syntax is trivial:
{
"name" : <signal name>,
"state" : <state machine script id>,
"target-state" : <target state>
}
The ClutterState instance is identified by its script id, and the target
state is resolved at run-time, so it can be defined both in
ClutterScript or in code. Ideally, we should find a way to associate a
default ClutterState instance to the ClutterScript one that parses the
definition; this way we would be able to remove the "state" member, or
even "style" the behaviour of an object by replacing the ClutterState
instance.
The implementation uses a signal emission hook, to avoid knowing the
signal signature; we check the emitter of the signal against the object
that defined the signal, to avoid erroneous state changes.
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.
In test-pixmap.c instead of using the GdkPixbuf API to load the
redhand.png image we now use the cairo API to load the png into a xlib
surface which wraps our Pixmap.
This test was the last thing that depended on the gdk API and since
it's more concise to use Cairo here which is a hard dependency for
Clutter this change means we avoid depending on GdkPixbuf directly.
This time, in Clutter core.
The ObjC standard library provides a type called 'id', which obviously
requires any library to either drop the useful shadowed variable warning
or stop using 'id' as a variable name.
Yes, it's almost unbearably stupid. Well, at least it's not 'index' in
string.h, or 'y2' in math.h.
Currently, the memory management in ClutterScript is overly complicated.
The basic design tenet should be:
- ClutterScript owns a reference on every object it creates
This allows the Script instance to reliably handle the lifetime of the
instances from creation to disposal.
In case of unmerge, the Script instance should destroy any Actor
instance, except for the Stage, and release the reference it owns. The
Stage is special because it's really owned by Clutter itself, and it
should be destroyed explicitly.
When disposing the Script itself, it should just release the reference;
any parented actor, or any InitiallyUnowned instance, will then be
managed by the parent object, as they should, while every GObject
instance will go away, as documented.
This commit is based on a patch by:
Henrik Hedberg <hhedberg@innologies.fi>
http://bugzilla.clutter-project.org/show_bug.cgi?id=2316
The internal copy of JSON-GLib was meant to go away right after the 1.0
release, given that JSON-GLib was still young and relatively unknown.
Nowadays, many projects started depending on this little library, and
distributions ship it and keep it up to date.
Keeping a copy of JSON-GLib means keeping it up to date; unfortunately,
this would also imply updating the code not just for the API but for the
internal implementations.
Starting with the 1.2 release, Clutter preferably dependend on the
system copy; with the 1.4 release we stopped falling back automatically.
The 1.6 cycle finally removes the internal copy and requires a copy of
JSON-GLib installed on the target system in order to compile Clutter.
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
Up until now, the "behaviours" member of an actor definition was parsed
by the ClutterScript parser itself - even though it's not strictly
necessary.
In an effort to minimize the ad hoc code in the Script parser, we should
let ClutterActor handle all the special cases that involve
actor-specific members.
While this is totally fine (0 in the pointer context will be converted
in the right internal NULL representation, which could be a value with
some bits to 1), I believe it's clearer to use NULL in the pointer
context.
It seems that, in most case, it's more an overlook than a deliberate
choice to use FALSE/0 as NULL, eg. copying a _COGL_GET_CONTEXT (ctx, 0)
or a g_return_val_if_fail (cond, 0) from a function returning a
gboolean.
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.
Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.
As a side note: this commit closes the oldes bug in Clutter's bug
report tool.
http://bugzilla.openedhand.com/show_bug.cgi?id=521
Currently, ClutterScriptParser will construct the object (using the
construct-only and construct parameters), apply the properties from
the ClutterScript definition, and eventuall will add children and
behaviours.
The construction phase should be more compartimentalized: the objects
should be constructed first and eventual children and behaviours
added. Then, once an object is requested or when the parsing process
has terminated, all the properties should be applied.
This change allows us to set up the actors before setting their
non-construct properties.
ClutterScript is currently a mix of parser-related code and
the ClutterScript object. All the parser-related code should
be moved inside a private class, ClutterScriptParser, inheriting
from JsonParser.
Instead of counting on a JsonNode pointer to survive we should take
a copy. This allows keeping unresolved properties across different
ClutterScript passes.
The block that allows setting a GObject property holding an object
instance is conditionally depending on the USE_PIXBUF define. This
makes it impossible to reference an object inside ClutterScript on
platforms not using GdkPixbuf.
The default floating point type for JSON is double precision; this means
that we need to conver to single precision when setting a property with
type G_TYPE_FLOAT.
JSON-GLib provides simple accessors for basic types so that we
can avoid getting the JsonNode out of a complex type. This makes
the code simpler to understand.
There have been changes in JSON-GLib upstream to clean up the
data structures, and facilitate introspection.
We still not use the updated JsonParser with the (private) JsonScanner
code, since it's a fork of GLib's GScanner.
