Clutter – If release 0.4 rocked hard, release 0.6 of Clutter will blow your mind away. Just to list some features landed in the past couple of weeks after ClutterScript got in:
- new event handling, borrowing from the W3C DOM event – that is, two event phases: capture, which traverses the scene from the stage to the actor that received the event, and bubble which traverses the scene from the actor to the stage. You can block the event chain in any point of both phases by simply returning
TRUEin the signal handlers (like GTK+); kudos to mallum and Pippin - improved text scaling, at least for downscaling at ~50%; kudos to Pippin
- build and test on win32 using the SDL backend, complete with VS2005 build files; kudos to tf
- time-based timelines, so you can define a
ClutterTimelineby giving its length in milliseconds; and without even breaking the API.
Still, there’s plenty more coming – so keep looking at trunk.
JSON-GLib – The code base has been consolidated a lot while working on ClutterScript, so I feel confident about making a release of the out-of-tree repository. The release is bagged, tagged and signed as json-glib-0.2.1 in the git repository ((As usual, at http://folks.o-hand.com/~ebassi/git/json-glib.git)). You can grab the tarball here. Work on seamless GObject-JSON (de)serialization will continue in the master branch towards a 0.4.0 release. Update@2007-10-16T23:30+0100: obviously, as soon as I got back home and checked the repository I found two bugs in the generator code; hence, brown paper bag release 0.2.1. Tarball, documentation and tag updated.
time-based!!! Rock!
I have this feeling that you are doing great job in clutter but that for some reason that eludes me you are tying it to OpenGL. Is it in your plans to abstract the event handling, scene programming, etc from the actual drawing so you can use cairo/X *only* to get things on the screen? It’s very possible that this is already in place and I’m just saying nonsense, sorry if that’s the case.
@xan:
we’re using GL mostly because of GL/ES. accelerated embedded hardware is getting everywhere, nowadays: iphone, zune, mobile phones, tablets – you name it. and GL is everywhere on the desktop as well.
we’d love to use cairo through glitz: it would mean using pango-cairo instead of our own renderer; it would mean dropping into cairo just like we drop into GL right now. the problem is that nobody is working on glitz and cairo-glitz, and that glitz does not support GL/ES so it’s completely wrong for embedded platforms.
@xan, its the 21st century – OpenGL is commodity on the desktop and soon to be in the hand. Why not take advantage of this ?
@ebassi Also OSX support and MX31 adventures,
http://www.clutter-project.org/blog/?p=34
Some people think a HW accelerated Cairo/RENDER is much more suitable as rendering system for a toolkit (see this). I tend to agree with that position, but even ignoring that clutter has lots of great, useful code that has nothing to do with GL and that could be reused in many places.
To make it perfectly clear: I’m not saying that using OpenGL *now* for you in your context is not the right choice, I’m just saying that I don’t see the need in forcing it on everyone. Of course those who write, decide, but hey, commenting on blogs is cheap :)