Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6

[Guillaume Emont <guillaume fluendo com>]

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[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].

I don't know that, I am a Pigment and PAF developer, not an Elisa
developer. 

> 
> 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[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.
> 

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[1] and the java timing framework[2]. 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[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.

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
exists/is maintained).

Cheers,

Guillaume

[1]
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreAnimation_guide/
[2] https://timingframework.dev.java.net/ 
> 
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list