Since I am implementing a new Gnometris rendering engine in Clutter, one of the issues that I've run in to is separating the different input models of GTK+ and Clutter. In the end, I decided to throw GTK+ out the window. That doesn't mean, however, that any of the underlying technologies need to go. In fact, I think a great deal of our stack will continue to survive without a GTK+ UI. Gobject is our baby. And, we're using lots of other things still, like Cairo and Pango--even though the whole UI and game is a 3D canvas.
To replace the top level menu system, I have been experimenting with different approaches. The following are some mock-ups of my thinking. First, none of our Glade files or existing translations are harmed in any way. I can just open up the XML file and walk over it with libxml2 to find out the names of the nodes I need to create and gettext, as usual.
Second, VI users rejoice: the main menu is accessed by pressing ESC.
Moving on, the approach that's stupid-easy would be to implement a linear-slider style menu system similar to the new K menu in KDE 4.x or also popularized by a particular portable music player. There would be a 'back' arrow on the left-hand side.
When a menu option is chosen, the menu animates a slide left revealing the sub-menu. However, two things detract from this approach. First, in localities where text is RTL, the flow would be non-obvious. Second, we're not really innovating and I'm not convinced that this approach is really the best way to do a hierarchical menu system.
Another way to do this would be to have animated, 'fly-in' pie menus that take advantage of muscle memory.
When the user chooses the highlighted menu item, the active pie flies backward to 50% of its size and goes 45% opaque. The new sub-menu flies in from behind the perspective of the observer at 100% opacity.
I haven't worked out the way to do keyboard bindings yet nor a way to easily implement the callbacks stored in the Glade files. Notice the highlight color is picked up from the Gnome theme. Something that's going to be very hard is getting pixel-level precision for the font rendering so that the magic that has been given to the font stack can continue to be taken advantage of no matter how many menu items are on the screen.
What do you think? Which way to go?
(For Luddites, the current 2D UI is not going away any time soon and will continue to be maintained.)

Comments
Save the clutter stuff for the block effects (tumbling row-collapses, etc.) and translucent score overlays. Maybe also add some elasticity to blocks, so that when they fall hard, they squish a little bit and then bounce back.
Some of the original (licensed) Tetris versions had nice Russian themed backgrounds that would change with each level. That might be nice, and also creates an opportunity for end-user theming.
Claudio
It just feels dirty.
Maybe constructively my only idea would be to make this functionality more discoverable, somehow. Then if it works for you, you get to tango with the accessibility people for a while ;)
Replacing all GTK UI with custom equivalents does not sound like a solution that will scale to multiple applications very well, and you are throwing out a lot by doing this (IME, a11y, theming, etc).
As others have already said you basically got rid of all a11y (you can argue that Tetris is not for blind people but a11y not just about blind people), got rid of alternative input methods and are asking for theming problems (most probably things will break in high contrast themes).
You also make the application harder to use for existing GNOME users ("where did the menu go?").
-- Emmanuele (ebassi), http://log.emmanuelebassi.net
-- robtaylor
Now the playing field in Tetris is clearly custom UI, so clutter doesn't sound like a bad choice. For the menus though, things are less clear.
I'd argue that "making Clutter and GTK input play together is hard" is a bad rationale for using custom UI there. I'd wonder why there was a problem (as does Emmanuele, by the look of it).
Secondly, if the aim is to expand use of clutter in GNOME then showing that it can be used in a normal GNOMEish application would seem useful. Having an application where all the UI has been ripped and replaced isn't exactly a good example.
Bonus points if you make the whole main game window rounded off on the edges.
Please please please?
-Garoth