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:
- Clutter is a nice way to move semi-3D things around on the screen to create “innovative” user interfaces. Its abstractions for actors and behaviours really give you something to work with compared to using OpenGL directly. But it’s still hard to create natural-feeling responsive applications and I don’t know exactly what’s lacking. It feels like there is a disconnect between the act of coding and the very dynamic UIs that the code creates. I sometimes feel I’d like to just 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, and trigger extra behaviour when they reach certain positions, or reach each other.
- Clutter is now a very basic API. You will need to implement a lot of simple functionality to create applications that act as today’s users expect. The Tidy “reference-implementation” example toolkit thing is not a shared library – it’s meant as an inspiration for you to do all this yourself, and it is itself not very complete. I don’t think that is a wise strategy, though rampant bad reimplementation is the standard in today’s mobile/embedded development projects.
- Neither you or Clutter should want to reimplement the huge amount of UI logic that is, for instance, in GTK+. Without reusing all that work, Clutter applications will generally have inconsistent or inadequate text editing, scrolling, focus, keyboard accessibility, right-to-left language support, etc. Applications will share little common API so it won’t be easy to throw new developers at your project. Somehow we need a way to use some GTK+ widgets in Clutter without them looking and feeling like they are visitors from an extra dimension.
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.
9 thoughts on “Clutter Tutorial done for now”
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.
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.
@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.
I really appreciate the tutorial. But if I see what I have to do to create my own actor:
This is the XXI century. Why do we still have to do this macro **** in C.Doesn’t look really appealing to new users ..
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.
@emmanuele: I ship many products without a GPU that have no need for a GPU or the cost of having a GPU on board.
@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.
“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:
@krh, yep – also see box2d and chipmonk. Pippin has been playing with them all.