Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6

[Emmanuele Bassi <ebassi gmail com>]

On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote:
 
> Dear Emmanuele,
> 
> Thank you for your opinion.
> As for the facts you mentioned, yes, there is stuff implemented in
> pigment-python that is not available in pigment:
>  - The only animation framework available for pigment is indeed the one
> of pigment-python. That sucks, I agree with you, and that's why I've
> been working on a new project: the PAF Animation Framework[1], that aims
> at being a standalone generic animation framework; it will be used by
> pigment in the future, and is designed to work well with other
> libraries: GTK+, clutter, any GObject library, or even any non GObject
> library. For the moment, it is in a "code skeletoning" and API
> definition stage, anyone interested is welcome to participate or simply
> give ideas. As for dates, I think a first version of PAF should be
> available in less than a month, and pigment 0.5 will make use of it
> (that should be available at the end of summer or at worst in autumn).

>  - The scene graph-like grouping system is part of pigment-python as
> well. There won't be any solution for that in pigment 0.3/0.4, but
> pigment 0.5 will provide a scene graph API in C (again, end of summer or
> autumn).

I'm actually kind of fuzzy on why you're not developing Elisa on top of
Clutter; I understand that the PyClutter bindings might be too near to
the C API and lack python-esque qualities - but bindings are still
bindings: I'm not overly attached to PyClutter, actually, and if I
somebody came up with a better implementation (and was willing to
maintain it) I would gladly "pass the torch"[1].

it seems to me that Pigment is trying really hard to get in twelve
months to the point where Clutter already is now; in six month we're
probably going to release Clutter 1.0, or an approximation of it[2].
Clutter is already providing a (portable) integration with GTK+, Webkit,
Cairo, GStreamer and event a physics engine - and we are committed to
release the current trunk as 0.8 before GNOME 2.24 is API frozen[3].

don't get me wrong: the PAF project is very nice, but reading from the
wiki[4] it looks a lot like a collection of pats in the back from the
Pigment development team, taking the Python API as a model[5] instead;
not to mention the fact that there's not only hardly any code, but no
API design except from what looks like a clone of the Pigment python
API.

I'm also not saying that Clutter is perfect: we have our share of warts
that we want to address, first and foremost the ability to create
dynamic layouts[6] in a 3D space. in any case, I have the distinct
feeling that the Elisa developers did not even try to look at Clutter as
a way to achieve their goals, save for inspiration.

and that's a real shame, at least for me, because I would have been more
than happy to help and contribute.

ciao,
 Emmanuele.

+++

[1] it's not a secret to anyone the fact that I don't really like
CPython and the current facilities needed to generate python bindings
from a GObject library.

[2] at which point we'll guarantee API and ABI stability for the whole
1.x series.

[3] the API differences between 0.6 and 0.8 are going to be minimal at
best: for this cycle we focused a lot on the low-level GL/GLES
abstraction layer called COGL, which will be exposed as part of the
public API and subject to the same guarantees we make for the Clutter
API and ABI.

[4] https://code.fluendo.com/pigment/trac/wiki/ExistingTimingFrameworks

[5] as far as my experience goes, this is never a good way to design a C
API, which is the goal in this case; you either end up with a poor copy
of the translatable concepts from a high level languages or to something
that's not really reimplementable in other languages and requires many
more iterations to be considered usable.

[6] http://bugzilla.openedhand.com/show_bug.cgi?id=815

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net