I’ve sent this email to the mailing list as well
as you might have noticed, work on Clutter trunk is progressing quite nicely. obviously, the big question is: “towards what? which features will land in 1.0? will it be called 1.0? when will it be released? what happens next? when do I get a pony?”
well, it was more than one question. actually, those were a lot of questions. apart from the pony one. that was just weird.
anyway.
let’s try to answer some of those questions, shall we? the first answer is: yes, the next stable release of Clutter will be called 1.0. we think it’s time to hit the “big 1″: we feel confident about the API, we feel confident about the feature set and we feel confident that additional features can be added without breaking the API/ABI contract we’ll have in place for the whole duration of the 1.x API series.
here’s the whole features list we are planning for 1.0; some of these already hit trunk:
- clean up COGL
- the COGL API is still in a bit of a flux; we’re trying to expose more features of the GPUs without resorting to use GL/GLES all the time, but this means dealing with a lot of cruft and dead ends we’d like to remove from the API before it’s sealed shut.
- documentation
- even though we have a near-100% API coverage in Clutter, some bits are still missing or not explained. we also need a Cookbook-style document, like the one I started for the Perl bindings.
- better build
- this means: single include file strategy for Clutter and COGL, unit testing, removal of the circular dependency between COGL and Clutter. all of this has landed in trunk in the past couple of weeks, with unit testing getting in on last Friday thanks to Robert Bragg. to break the circular dependency, COGL now has its own fixed-point type, to which
ClutterFixed maps transparently; and a Color type, which should be completely opaque to the user (conversion functions are provided). Clutter will still use the ClutterFixed and ClutterColor types and API.
- new tweening/simple animation API
- this new API should replace the Effects API, hopefully with something more powerful but flexible. the current approach is to use something that looks a lot like the JavaScript tweening API. the bug number with the implementation is: 1014.
- unified text actor
- this would remove the
ClutterLabel and ClutterEntry actors in favour of a generic Text actor, with the ability to be set editable on demand. the separation between editable and non-editable actors is mostly a style/theme issue, and thus should pertain to toolkits written on top of Clutter; this actor would make text displaying and text editing extremely easy for developers, who would then only care about styling. the bug number with the implementation is: 1106.
- threaded
glXSwapBuffer()
- using a separate thread (if the application has threading enabled) to swap the GL buffers on GLX. it has proven to be a performance gain, but it still requires some testing. the bug number with the implementation is: 1118.
- asynchronous images loading from disk
- along with PBOs and some caching, this would minimize blocking when loading an image from disk into a Texture. the bug number with the implementation is: 1144.
- multitexturing support
- this would be a COGL feature first, and if time permits, exposed inside
ClutterTexture API. the bug number with the implementation is: 1163.
- mesh API in COGL
- already discussed on the mailing list, landed in trunk.
- disjoint paths and clip-to-path
- a change in the semantics in the COGL path API that would make it more Cairo-like, and allow non-rectangular shaped clip areas. the bug number with the implementation is: 1172.
- promote the Pango renderer to public API
- this has already landed in trunk, under the CoglPango namespace (to avoid eventual namespace collisions).
- backface culling
- already landed, a simple function the toggles backface culling and that should be used in the paint implementation of an actor.
- include the ClutterCairo actor in Clutter core
- since Clutter already depends on Cairo for the Pango renderer, we can exploit the dependency to kill off the smallest of the integration libraries. this is still on the “undecided” list of things because it can be a performance hit for Clutter-based applications if the application and toolkit developers are not careful when using cairo. the bug number with the implementation is: 1251
- unify the linear and bspline path behaviours
- instead of having two behaviours, a single behaviour capable of switching between the two path modes - or even mixing them - would be preferred. the bug number with the implementation is: 1252.
- move the repository to git
- while technically not a feature, we’re in the process of putting core, all the integration libraries, bindings and toys into a set of git repositories - split up, this time.
since some of the items have already landed in trunk, we might be ableto squeeze in some other GPU-related feature, like exposing the GL lighting API (see bug number: 1254).
the release date for 1.0 depends on the stabilization process of the features that are going to land in this cycle. hopefully, we’ll be able to keep up with the 5/6 months cycle we have followed until now - so 0.9 should be out by December 2008 and 1.0 should be ready by January/February 2009.
after the 1.0 release, the API in Clutter core will be permanently frozen for the 1.x series: only additions and deprecations will be allowed, but no changes or removals. we obviously are going to add features on the stable series, so you can expect a 1.2 and then a 1.4 and then a 1.6 and possibly more. we also know that stagnation is an issue, so we’re going to branch fairly early for the 2.0 cycle (ideally soon after 1.0) so that it will be possible to keep experimenting without ruining the fun of application and integration libraries developers. we don’t have a release date for 2.0 yet, but we expect the 1.x API series to continue for at least a couple of years.
stay tuned for more news from the Clutter team!
