Now that Clutter 0.6 is out, I found the time to finish the planned sections for the Clutter tutorial that I mentioned in December, for Openismus. Here is the html version and a PDF, though of course the PDF doesn’t have the nice links into the API reference documentation and the links to the actual files of the examples.
The guys at OpenedHand haven’t had time to review this yet, so be aware that there could be significant errors. But I think it’s mostly accurate, useful, and unique, though the appendices and full example are obviously lacking. I’ll try to keep it up to date and correct as I get feedback.
Having done all this investigation into Clutter, I have formed some opinions:
These problems could probably be solved by lots of hard work by smart people. I don’t know what the near-future strategy for Clutter is, so I don’t know if the current state is intentional or if anything particular is planned. It’s certainly getting better all the time.
March 3rd, 2008 at 3:06 pm
It seems to me that Clutter is not appropriate for an embedded device that lacks 3D acceleration. Even if you do have 3D acceleration in your device, you still have a lot of work cut out for you because the Clutter UI is too basic for more complex interfaces. So the result would be a mismash. It is definitely getting better all the time, however I would not target Clutter to only 3D accelerated devices - it would make more sense to first have it do really well on unaccelerated hardware and allow the option of 3D acceleration.
March 3rd, 2008 at 3:18 pm
sean, this is the XXI century and after the iphone hardware acceleration is landing basically everywhere (see openvg and gl/es 2.0). there’s no point in targeting software accelaration, really.
March 3rd, 2008 at 4:17 pm
@sean: There is nothing stopping someone from writing a software renderer backend to Clutter (infact see http://svn.o-hand.com/view/clutter/branches/clutter-software/ ..) or use a software GL implementation. However from day one we designed clutter to run on a GPU and much of its internal design is expecting that (I do not think you can take full advantage of something like OpenGL if you go software initially and then port to OpenGL). Also I think its a fair assumption that GPU’s are commidity on desktops nowadays and, thanks to the iphone, its going the same way on devices also. You simply arn’t going to get true iPhone like effects without a GPU - thinks like Canola pretty much prove this. They are good, but not *that* good. They are not effortless.
@murray & sean: Clutter is not meant to be a GTK+ reimplementation - if we wanted that we could have written a GDK on top of GL or some such. Its a mid level layer (think between GDK & GTK) for building fast visually impressive and animated UI’s that are specific to an implementation - *not* for uniform desktop applications - you have GTK for that!. Its fine wanting a lot of high level functionality until you want to differenciate and then it just gets in the way. Clutter makes it quick to build that high level functionality specific to your particular UI.
March 3rd, 2008 at 4:19 pm
I really appreciate the tutorial. But if I see what I have to do to create my own actor:
http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/apas02.html
This is the XXI century. Why do we still have to do this macro **** in C.Doesn’t look really appealing to new users ..
March 3rd, 2008 at 4:22 pm
writser. you can use C++ with cluttemm. There are Python bindings too. You are not forced to use C with Clutter, just as you aren’t forced to use C with GTK+. Sometime I might get around to creating a cluttermm version of the tutorial.
March 3rd, 2008 at 4:42 pm
@emmanuele: I ship many products without a GPU that have no need for a GPU or the cost of having a GPU on board.
March 3rd, 2008 at 5:03 pm
@sean right, but in a year or two.. Also there are plenty of other toolkits out there which dont need a GPU, they’ll never look as fluid or use as little CPU as Clutter though - but that may not be important. Clutter is just another choice.
March 3rd, 2008 at 8:24 pm
“put actors on a rail, twist that rail about, connect some actors together with struts or springs, start them moving, let the user push and pull them around within constraints,” is a pretty good description of what akamaru lets you do:
http://people.freedesktop.org/~krh/akamaru.git/
March 3rd, 2008 at 9:16 pm
@krh, yep - also see box2d and chipmonk. Pippin has been playing with them all.