Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
- From: Guillaume Emont <guillaume fluendo com>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
- Date: Mon, 21 Apr 2008 21:21:30 +0200
Le lundi 21 avril 2008 à 17:10 +0100, Emmanuele Bassi a écrit :
> 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, 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".
I don't know that, I am a Pigment and PAF developer, not an Elisa
> it seems to me that Pigment is trying really hard to get in twelve
> months to the point where Clutter already is now;
Again, thank you for your opinion, but I don't want to feed any troll.
> in six month we're
> probably going to release Clutter 1.0, or an approximation of it.
> 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.
> don't get me wrong: the PAF project is very nice, but reading from the
> wiki it looks a lot like a collection of pats in the back from the
> Pigment development team, taking the Python API as a model 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
This is a work in progress, and for the moment the only API definition
is in the UML file (misc/paf.xmi in lp:paf). I am currently working on
writing the code skeleton and code documentation in order to have a
clean and clear gtkdoc describing the API.
The main models for the design of the API are the animation part of
Apple's CoreAnimation and the java timing framework. The big
common point between pigment-python's animation layer, PAF and
CoreAnimation is that they try to address the problem of interactive
animations. Implicit animation is therefore a strong common point, but
that doesn't make these APIs equal.
Also, the wiki you cite is not a definition of PAF. It is only a quick
study I did on existing animation frameworks with a few use cases, to
help me find out the features that PAF needs to rock. In short: that
document precedes PAF and the PAF 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 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.
Again, I don't know, but I think you can ask these questions on the
mailing list of Elisa. Also, I think that Elisa is quite modular, and
that a Clutter front-end could be written for it (I think there was a
GTK+ front-end for Elisa at some point, but I don't know if it still
>  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.
>  at which point we'll guarantee API and ABI stability for the whole
> 1.x series.
>  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.
>  https://code.fluendo.com/pigment/trac/wiki/ExistingTimingFrameworks
>  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.
>  http://bugzilla.openedhand.com/show_bug.cgi?id=815
> Emmanuele Bassi,
> W: http://www.emmanuelebassi.net
> B: http://log.emmanuelebassi.net
> desktop-devel-list mailing list
> desktop-devel-list gnome org
] [Thread Prev