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