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

[Tristan Van Berkom <tristanvb openismus com>]

Exciting topic.

Just a few comments scattered through the email...

On Tue, 2011-09-06 at 14:26 +0000, Benjamin Otte wrote:
> 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 

For the record, having a common serialization framework would make
things much, much easier for the guys trying to generate this stuff.

If, for instance GtkBuilder was indeed GBuilder, and would have been
the obvious choice for ClutterScript... 

The result would have been:
   - Someone creates clutter-gtk widgets (already done)
   - Someone easily integrates the clutter widget into Glade catalog
     (some have done privately, quite easy to do as it stands)
   - The 'GtkClutter' widget could simply extend the definition
     of it's xml with the GBuildable interface, simply by creating
     ClutterActors from the embedded GBuilder xml.

All ClutterActors, simply by nature of being GObjects, would be
automatically supported by Glade, the only remaining work to be
done to create clutter projects in Glade would be the UI.

However unfortunately, things did not go down this road, and so
we are that much further from editing ClutterScript, at least
from Glade (and combined with GTK+ from Glade).


> 
> > 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?

Something that Juan Pablo and I have wanted to do over the years is
introduce a container interface, perhaps in the UI toolkit level or
even in libgobject.

If we had a common infrastructure for handling containers then tools
like Glade can do more with less code, i.e. we can interact using that
interface, introspect packing properties and the like.

Some examples where this would be useful particularly to us:
   - Actions contained in Action Groups
   - GtkCellRenderers owned by GtkCellArea objects
   - GtkTextTag owned by GtkTextTagTable

Without considering any new implications, the way we've imagined
doing this would be to:
  a.) Make GtkContainer implement the GContainer interface, this means
      widgets and containers can keep interacting in the normal way
  b.) GContainer interface now would exist, implement it for
      GtkTextTagTable, GtkActionGroup, GtkCellArea...
      (NOTE: This would probably also reduce the code duplicated
      between GtkCellArea and GtkContainer regarding packing
      properties) 
  c.) Now external tools that need a better/more unified api can
      leverage GContainer instead of special casing all of these
      separate cases of container <-> child relationships.

I guess the challenge is to design a GContainer interface that satisfies
the requirements of both ClutterActors and GtkWidgets (someone will have
to sacrifice and make a change, since actors implementing the
ClutterContainer interface have a different way of representing packing
properties).

> 
> >   - 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
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list