Clutter Toolkit

Prompted by Z-bo's question of what is there to gripe about CSS, I thought I'd point out the Clutter toolkit:

Clutter is an open source software library for creating fast, visually rich, portable and animated graphical user interfaces.

Clutter uses OpenGL (and optionally OpenGL|ES for use on Mobile and embedded platforms) for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.

Similar to Bling, it explores how GPU abstractions should be exposed to UI layout designers. I think there will be a lot of turmoil in this space over the next few years. Some related projects of interest are PixelBlender (with its integration into Flex 4) and similar projects in the Silverlight community. Another approach is to try to not change anything, as in a new GPU-accelerated Firefox branch. The only comparable approach I know of in the PL space is Conal Elliott's Vertigo, but that was not really about structured UI.

Edit: link fixed.

Edit 2: two big motivations here 1) performance on mobile devices and 2) enabling new types of UIs, such as physically realistic ones

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Link to Clutter is broken.

Link to Clutter is broken.

Already linked it on my tumblelog :)

Looks like I am moving in the right direction here, at least as far as gathering the right resources to study.

Long side note:
This is actually part of my blog series on using message handling protocols to built robust abstractions. I've not really published anything in this series yet, because part of it is that as I write the essays, I am exploring new theories in design I had not considered before...

I'm also considering using either OMeta, Maude, or Tempo to kind of demonstrate my points (Tempo is a really old language that doesn't get cited enough for seemingly groundbreaking work that is basically only now being explored again by OMeta, LLVM/Phoenix and Maude).

I also think in general that the idea of "little languages" (like CSS) and arbitrary things like "frameworks" are stupid and ugly, and that is the root of the problem with things like CSS. I was surprised to see recently that Garlan updated his Architectural Mismatches paper to claim such things still exist; to me, this is the saddest paper I've ever read in computer science. 14 years of "progress" and still no mathematical analysis. This reflects my firm belief that buzzwords do not solve problems, and rarely improve on defining ill-defined ones. Yet the original Architectural Mismatches paper is cited over 500 times... and very little survey or analysis has been done after the fact that really appears to look at these issues.

Alan Kay has this great quote in his The Computer Revolution Hasn't Happened Yet OOPSLA '97 speech where he says the sad thing is that the only thing that motivated people to study architecture was the Internet forcing them to; now that people have discovered hash tables and map/reduce, we're back at square one. I feel these buzzwords make it really easy pretend you're studying architecture. But I feel the only way to study architecture is through programming language theory. Perhaps that is what Kay meant when he called The Art of the Metaobject Protocol the best book on OO that was written "in the last 10 years", because otherwise the comment doesn't make much sense, since that book is entirely about procedural 3rd generation OOPL's and doesn't really reflect his true vision of billions of syntax-directed interpreters cooperating with each other.

Programming language theory really needs to step up and show these "architects" how to solve their "mismatch" problems, and break down these "Frameworks" into "components" and break down these "little languages" into "composition systems".

My current position is that these ridiculous abstract contraptions like "Model-View-Controller" and "Model-View-ViewModel" and "Presentation-Abstract-Control" and "Web-MVC (Model 2)", etc. need to be studied from the standpoint of automata theory and figure out how to get a grip on how these things are supposed to interact. I just kind of have to hash out how this would work.