after all the changes in this series of blogs, and all the big changes I tried to introduce in them, this is mostly a coda — one in which I just want to mention a couple of new features that don’t fall in the previous apocalypses but that I think are interesting nonetheless.
ClutterTimeline and ClutterAlpha
the timeline class gained a new property, repeat-count which replaces the venerable loop one; whilst loop would just make the timeline loop indefinitely (until forcibly stopped), repeat-count allows you to set a ceiling to the number of repeats.
another change in the Timeline class is the introduction of the progress-mode property, which allows you to control how the progress property is computed. this effectively deprecates ClutterAlpha, even if the class itself hasn’t been marked for deprecation (as we still need it for other API).
these two changes hopefully will make using ClutterTimeline a better experience, and remove some custom code.
Support localizable strings in ClutterScript
if you currently define UI elements in ClutterScript you’ll notice that all the strings are not translatable; this is clearly sub-optimal, and prevents people from actually writing proper applications using this format, just like they do with GtkBuilder.
I recently added the ability to describe translatable strings inside the JSON format, using a syntax like:
{
...
"a-label-property" : {
"translatable" : true,
"string" : "A Translatable String",
"context" : "Some Context",
"domain" : "Gettext-Domain"
},
...
}
the domain and context members are optional, and allow you to specify a gettext domain and context for a specific string; you can assign a domain to the ClutterScript instance, using clutter_script_set_translation_domain(), or use the Gettext domain specified by the application itself upon initialization with bindtextdomain().
obviously, this is just a step: the real support for localization can only come after intltool is updated to handle the JSON format used by ClutterScript, to extract the translatable strings and place them into the POT file; this is planned, but it’s not ready yet.
see you in 6 months!
well, I hope you enjoyed this series of blog posts; oh, more accurately: I hope you haven’t been bored to death by it.
what will happen in six months is, very likely, a 1.12 release of Clutter, with a couple of other Apocalypses landing (a way to animate layout management by using the easing states and transition API instead of the half-aborted animation API inside ClutterLayoutManager; and the ClutterActorModel API, to get rid of the ClutterClones).
ideally, I’d really like to have the first 2.0 alpha release at about the same time — in order to give people the feel of the changes, as well as time to port their applications and start complaining about the missing functionality while I can still add, change, or remove API. what’s certain is that between 6 and 12 months I want to have Clutter 2.0 out of the door and into your systems; whether or not that will happen sooner or later it entirely depends on the time I’ll be able to spend on it, as well as the contributions I may receive. so, if I have to close with a familiar exhortation: patches welcome!
until then, have fun with Clutter!