GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Emmanuele Bassi <ebassi gmail com>]

[Cc:ing clutter-devel-list, but IMNSHO the discussion should happen on
gtk-devel-list; I'm subscribed to both so please don't Cc: me - I don't
need three copies]

hi all;

during the Desktop Summit in Berlin there have been multiple talks about
the future of GTK+ and Clutter.

part of the discussion was about trying to understand where both pieces
of the puzzle stood with regards to one another, and how the future of
the Gnome platform would look like with either, or both toolkits.

GTK encodes a great deal of knowledge; it's the result of 10+ years of
development, and has fairly complex widgets that cannot be simply
chucked away, or re-implemented on top of a new toolkit. on the other
hand, it still behaves like an old style toolkit, and it's lacking in
various features, like canvas support, animations, 3D support and
hardware accelerated drawing and composition.

Clutter can be used to write new toolkits, as the Mx and St projects
used by Moblin/MeeGo/Gnome and the Gnome Shell demonstrated. it provides
a canvas-based, 2D-layer-in-3D space environment and an animation
framework, and it's using hardware acceleration for drawing and
compositing of layers. Clutter encodes 5+ years of development as well,
including lessons learned from the development of GTK itself.

there are three potential routes involved in a future roadmap for GTK+
4.0:

  a) drop GTK+, move to Clutter and port the complex widges over;
  b) re-implement Clutter inside GTK+;
  c) use Clutter between GDK and GTK+;

the a) and b) options are going to require resources we don't currently
have, and would end up consuming vasts amount of time, which we might
not have if we want to maintain GTK+ as a viable toolkit for native
cross-form-factor and cross-platform GUI development.

tl;dr: reimplementing sucks on both sides, so we might as well try to
make both kids play well together and strengthen the application
development story of the Gnome platform.

* common parts or concepts:

a huge chunk of Clutter behaves like GTK, which is nice.

our layout system uses a two-pass size negotiation mechanism, with
height-for-width and width-for-height size request and an allocation
phase that allows both fixed layout and fluid layout managers. it is
somewhat less complex than GTK+'s, but not any less flexible.

Clutter does not have many UI elements: text, rectangle and texture. we
also have clone, which repaints an existing actor at a different point
in the scene graph, and a CairoTexture which is a wrapper around a Cairo
image surface (currently).

Clutter only has two containers: Group and Box; Group has a fixed layout
manager, like GtkFixed, while Box allows to change the layout manager
policy using delegate objects (a Box can then become a grid, a table or
an horizontal/vertical layout).

Clutter's backend system has already been ported to Windows and OS X,
and it's fairly small.

Clutter's windowing system abstraction only has top-level surfaces, and
each sub-element of the scene graph is not backed by native windows,
just like GDK (minus the input-only GdkWindow).

the Clutter UI description format is JSON and not XML because I honestly
don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong
position in the stack (GTK instead of GLib) and exposing the wrong API
(GMarkup to create custom parsers); on the other hand, ClutterScript
made JSON-GLib possible. :-)

* additional features:

Clutter also has some cool concepts like Constraints, which are similar
to SizeGroups/Alignments; Actions, which are objects that set up actors
to provide high level concepts like click/long-click, gesture
recognition, drag and drop; and Effects, which are post-processing
filters that use GPU shaders or rendering to offscreen framebuffers.

as I said above, layout management for containers can be deferred to
delegate classes instead of being hardcoded inside the container itself.

the whole animation framework of Clutter is based on GObject property
introspection, and allows animating not just actors but essentially any
GObject class. objects can also implement the Animatable interface to
override the default behaviour of the animation API. Clutter has simple
tweener-like API; key frame based animators; and state machines.

generally speaking, with Clutter we're trying to go towards a small core
plus delegation model, instead of a pure OO model, which is more suited
for quick prototyping.

* differences:

the major difference between Clutter and GDK is that Clutter provides
its own (very much internal) windowing system abstraction. this means
that Clutter has events, devices, and windows that map really closely
GDK concepts but are not GDK's own.

the good side is that this abstraction is generally not visible to
anyone, and it's fairly limited. I've been against providing public API
that abstracted the windowing system features in Clutter, and that
allows us to switch internally to GDK for most of our windowing system.

Giovanni Campagna recently submitted a GDK backend for Clutter[0] which
I'm fairly keen on merging during 1.9 (the cycle for Gnome 3.4) and
using as the default backend when compiled on X11.

there are some differences still, though; namely, the windowing system
abstraction is half in Cogl and half in Clutter. Cogl necessitates to
control the surface used to draw on, especially on X11 and GLX; Clutter
provides just the event and device handling for the input on the stage
window.

we are also planning to move the core clock down to Cogl, since it's
strictly tied to the GL implementation. the clock is what Clutter uses
to drive the paint cycle, the event handling and the animations for
each frame.

* how to bring this all together (without killing puppies):

obviously, we cannot shove Clutter as it is inside GTK and call it a
day: both Clutter and GTK would require extensive API changes.

there are a couple of different ways of incorporating Clutter inside
GTK. one is going the CoreAnimation route, and have GtkWidget exposing a
ClutterActor as part of its class; essentially, any GtkWidget would be
able to embed a ClutterActor - and be embedded inside a ClutterActor.

for instance, a UI would look like:

  GtkWindow
  +---- GtkGrid
        +---- GtkMenu<menubar>
        +---- GtkGrid
              +---- GtkGrid<sidebar>
                    +---- ...
              +---- actor -> viewport with coverflow effect
                    +---- GtkButton<skip_prev>
                    +---- GtkToggleButton<play_pause>
                    +---- GtkButton<skip_next>
              +---- GtkStatusbar

which is the equivalent of merging the Clutter-GTK library inside GTK
itself, sharing the GDK windowing system and plugging the redraw cycle
of Cogl/Clutter as the main driver for GTK.

another method is essentially to rebase GtkWidget on top of a somewhat
streamlined ClutterActor, with each GtkWindow being the equivalent of
the present day ClutterStage, and leaving GTK to provide
containers/layout managers, complex widgets like GtkTreeView and
GtkTextView, and top-levels like Gtk[App|File|Font|Recent]Chooser*.

+++

in any case, I have various plans for changing Clutter's API for 2.0
that would impact the decision:

  - drop ClutterStage as an Actor;
  - make ClutterActor instantiatable;
  - move ClutterLayoutManager to be a delegate used directly by
    ClutterActor;
  - drop containers and make the scene graph explicitly part of the
    ClutterActor API;
  - drop Rectangle, Texture, and CairoTexture sub-classes and move
    towards a delegate approach for painting the contents of the
    actor;
  - fully retained painting model using primitives;
  - rework the animation framework, and decide whether or not to
    continue using GObject properties.

these plans mostly depend on the amount of time I'll be able to devote
to Clutter, and the eventual contributions from the community.

ciao,
 Emmanuele

[0] https://bugzilla.gnome.org/show_bug.cgi?id=657434

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi