Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Benjamin Otte <otte gnome org>]

Emmanuele Bassi <ebassi <at> gmail.com> writes:
> 
>   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+;
>
I would translate that as:
a) tell GTK developers their code is crap
b) tell Clutter developers their code is crap
c) make Clutter and GTK developers work together on the best of both worlds

I have a good idea what solution causes the least tension here... ;)

> 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. 
> 
I still maintain that the person that writes and maintains the parser and the UI
for editing gets to decide what format we use. I can handcraft JSON and XML
files that test GTK. I can even handcraft binary files to break things if I need
to. And nobody else does care, because they'll all be using the editor anyway.
(right? :))
Last but not least, I can also live with JSON existing in Clutter and XML
existing in GTK. One of them will not work on the GTK level, so 

> 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.
> 
So, let's say we think these concepts are awesome and we want them in GTK. In
particular, actions are something I'd want in GTK preferably right now so that
when we do the switch in event bubbling, there's not that many event handlers
left to fix. How do we do that? We don't want to introduce GTK API that is in
effect identical to the Clutter API. And we don't want to depend on Clutter. Is
there a solution that can work for this?

> 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.
> 
There is one thing I'd like to do, and that is providing state for the drawing
operations we do in GTK. An entry would no longer need to do complex
computations whenever it draws[1] (frame, text, progressbar and icons) and
doesn't need to do complex border, margin and padding computations for each of
them, but it would just have Frame, Text, Progressbar and Icon render objects,
that took care of this job. They'd of course need to hook into the CSS theming
infrastructure to get their rendering informations. And it seems to me it's a
good idea to use ClutterActors for that.

If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I
don't think that matters a lot. In particular because changing from one to the
other just requires changing 3 lines of code. ;)

>   - drop containers and make the scene graph explicitly part of the
>     ClutterActor API;
>
The question of how to present containers in the public API is an interesting
one. I poked you about this on IRC, so I won't go into the arguments here and
don't want you to answer, but I'll point it out anyway so people reading this
can think about it:
There is 3 consumers of a "container" interface to an Actor/Widget:
1) someone implementing a subclass of the Actor/Widget
2) application developers using Actors/Widgets and reading API documentation
3) development tools like glade
They all need to be able but not confused about what they are allowed to do and
what they aren't allowed to do. So group 1 needs the ability to add child actors
to any actor, but groups 2 and 3 should never do that unless the actor really is
a container.
Basically, you want to expose a protected add/remove() function and only make it
public for real containers. Do we have a way how we support this in GObject?

>   - 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;
>
Could you elaborate on the reasons for that a bit more? From looking at WebKit
(who has a render object/html element split), GTK and Clutter (who don't, but
apparently want to have) and talking to Tim about Rapicorn[2] (which has very
few "real" widgets that render themselves and everything else is a container of
those widgets) I've never managed to find the ideal split here. Because the
render objects definitely need to be used for layout (their size is kinda
important) and input (you need to know if you clicked on them after all). And at
that point they are pretty much full-fledged widgets...

>   - rework the animation framework, and decide whether or not to
>     continue using GObject properties.
> 
I'd like some elaboration on the pros and cons here, too. But I can get that
using beers at the Summit, too. :)

Benjamin


1: http://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c#n3456
2: http://rapicorn.testbit.eu/rapicorn.html