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