Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sat, Jun 14, 2008 at 9:17 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Sat, 2008-06-14 at 15:27 +0200, Andre Klapper wrote: Am Mittwoch, den 23.04.2008, 10:23 +0100 schrieb Emmanuele Bassi: Le lundi 21 avril 2008, à 17:10 +0100, Emmanuele Bassi a écrit : 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]. we plan to release 0.8 by June, at this point; we have some pending items to merge into trunk before we can start pushing out developers snapshots. so this is still the plan? just saw that 0.7.0 was released yesterday, and GNOME API freeze is July 28. took a little bit more than expected, but the plan still holds: 0.8.0 will be released before GUADEC. we'll keep pushing out developers snapshots for people to test and play with the new API and features. AFAIK, only Gnome Games and some work on GThumb full screen previews that are modules inside GNOME have officially started using Clutter. If we can get buy-in from the GThumb (I'm in) we can depend on just 0.8 instead of on 0.6.2 and 0.8 for 2.24. Though, at this point, my work won't be ready by the feature freeze so it's not going to make it in to 2.24 anyway. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Am Mittwoch, den 23.04.2008, 10:23 +0100 schrieb Emmanuele Bassi: Le lundi 21 avril 2008, à 17:10 +0100, Emmanuele Bassi a écrit : 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]. we plan to release 0.8 by June, at this point; we have some pending items to merge into trunk before we can start pushing out developers snapshots. so this is still the plan? just saw that 0.7.0 was released yesterday, and GNOME API freeze is July 28. andre -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sat, 2008-06-14 at 15:27 +0200, Andre Klapper wrote: Am Mittwoch, den 23.04.2008, 10:23 +0100 schrieb Emmanuele Bassi: Le lundi 21 avril 2008, à 17:10 +0100, Emmanuele Bassi a écrit : 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]. we plan to release 0.8 by June, at this point; we have some pending items to merge into trunk before we can start pushing out developers snapshots. so this is still the plan? just saw that 0.7.0 was released yesterday, and GNOME API freeze is July 28. took a little bit more than expected, but the plan still holds: 0.8.0 will be released before GUADEC. we'll keep pushing out developers snapshots for people to test and play with the new API and features. ciao, Emmanuele. -- 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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Wed, 2008-04-23 at 10:19 +0200, Vincent Untz wrote: Le lundi 21 avril 2008, à 17:10 +0100, Emmanuele Bassi a écrit : 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]. I think people now understand some of the arguments that might make a few release team members happy ;-) Can we also assume that 0.8 will be maintained during the GNOME 2.24 lifetime? we plan to release 0.8 by June, at this point; we have some pending items to merge into trunk before we can start pushing out developers snapshots. all the releases with the same even micro version number are API and ABI stable; depending on the amount of bug fixes we do micro releases for the stable cycle as well (I recently did a 0.6.2 release), so yes: 0.8 will be maintained for the entire duration of GNOME 2.24. this obviously holds for the rest of the libraries in the suite (clutter-cairo, clutter-gtk and clutter-gst for instance). ciao, Emmanuele. -- 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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
2008/4/21 Luca Ferretti [EMAIL PROTECTED]: ... Emmanuele, IMHO the better and faster way to show everyone the Clutter goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 weeks ;-) That would be awesome. Here's the bug: http://bugzilla.gnome.org/show_bug.cgi?id=415816 Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Tue, Apr 22, 2008 at 1:41 AM, William Jon McCann [EMAIL PROTECTED] wrote: 2008/4/21 Luca Ferretti [EMAIL PROTECTED]: ... Emmanuele, IMHO the better and faster way to show everyone the Clutter goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 weeks ;-) That would be awesome. Here's the bug: http://bugzilla.gnome.org/show_bug.cgi?id=415816 http://folks,o-hand.com/iain/clutter-flow.png here's something I knocked up last night While its clearly not finished yet (I was tired and my caffeine ran out) Its interesting that the part I was finding tricky was getting the album data out of RB rather than the clutter code to do this (although it is copied from the coverflow demo thats been kicking around) So far: [EMAIL PROTECTED]:~/rhythmbox/plugins/clutter-flow$ wc --lines clutter-flow-plugin.c 290 clutter-flow-plugin.c Most of that is the standard c-plugin boilerplate iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, 2008-04-21 at 21:37 +0200, Luca Ferretti wrote: Il giorno lun, 21/04/2008 alle 17.10 +0100, Emmanuele Bassi ha scritto: On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: 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]. Emmanuele, IMHO the better and faster way to show everyone the Clutter goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 weeks ;-) four weeks? what would I do with the rest of the three and a half weeks, then? ;-) seriously, though: I though about it, and I actually preferred adding a slideshow to eog. you know, something that didn't scream please, apple, sue me; and frankly I find coverflow on the clunky[1] side of usable browsing. plus, everyone and his sister has that[2]. :-) so, here's a by no means complete Ken Burns style slide show plugin for eog that I wrote this morning (took me approx. 2 hours, most of which spent finding out how to extract stuff from eog): http://folks.o-hand.com/ebassi/eog-ken-burns-clutter-plugin.ogg patch against eog trunk: http://folks.o-hand.com/ebassi/eog-ken-burns-clutter-plugin.patch caveat: it's pretty ugly in terms of extracting the images list out of eog - ideally, one would like an API to preload the next couple of images at each cycle, so that eog_image_get_pixbuf() will work without me getting the path of the image and calling gdk_pixbuf_new_from_file_at_size() or using an asynchronous callback complicating the code. it's also not fullscreened for debugging purposes, but it's quite easy to call gtk_window_fullscreen() on it. obviously, it's completely optional - but if you have jhbuild you can already compile it by simply building clutter and clutter-gtk before eog. by the way: I totally blame lucasr - he should be the one doing it. ;-) ciao, Emmanuele. +++ [1] not the actual effect: I think that the amounts of tweaks to make it look real doubled the amount of actual code needed to make it work. [2] and everyone is trying to use it for the wrong thing. -- 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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
+1 Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, 2008-04-21 at 00:33 +0100, Gustavo J. A. M. Carneiro wrote: If Clutter is built on top of opengl exclusively (correct me if I'm wrong), then: 1. It does not use Cairo; cairo can be used to draw on a ClutterTexture, using the clutter-cairo actor. 2. It might not work if opengl is not available; it will work on Mesa with software rendering. not as good, and not as fast, but it will still work. 3. It might not integrate nicely with gtk+ printing; minor point, in this case: you rarely want to print a tetris field. ;-) Clutter is meant to build mostly UIs, not content; and content can be drawn with Cairo and displayed on top of Clutter. ciao, Emmanuele. -- 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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, 2008-04-21 at 02:04 +0200, Florian Boucault wrote: Hello! Pigment should be taken into account and not be dropped because it's Python-only since it is not. Here is a C example of a Cairo sphere rendered on a Pigment drawable: https://code.fluendo.com/pigment/trac/browser/trunk/pigment/examples/sphere.c far from me to detract from Pigment (I recently saw it's growing a GLES backend), while the Python API is very nice, the C API is nowhere as nice as Clutter's; its entire animation framework and item manipulation is done inside an high level language, while the C layer must manipulate matrices which is very GL-like; and if I wanted to wrap it in, let's say, Perl I'd have to reimplement it all. while this might be good for a low level library like D-Bus, where syntactic sugar should hide the gory details of the marshalling and demarshalling of data, I'm not as sure that a canvas should work the same way (I'm talking here as a bindings and an application developer, not as a Clutter developer). ciao, Emmanuele. -- 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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Le lundi 21 avril 2008 à 08:06 +0100, Emmanuele Bassi a écrit : On Mon, 2008-04-21 at 02:04 +0200, Florian Boucault wrote: Hello! Pigment should be taken into account and not be dropped because it's Python-only since it is not. Here is a C example of a Cairo sphere rendered on a Pigment drawable: https://code.fluendo.com/pigment/trac/browser/trunk/pigment/examples/sphere.c far from me to detract from Pigment (I recently saw it's growing a GLES backend), while the Python API is very nice, the C API is nowhere as nice as Clutter's; its entire animation framework and item manipulation is done inside an high level language, while the C layer must manipulate matrices which is very GL-like; and if I wanted to wrap it in, let's say, Perl I'd have to reimplement it all. while this might be good for a low level library like D-Bus, where syntactic sugar should hide the gory details of the marshalling and demarshalling of data, I'm not as sure that a canvas should work the same way (I'm talking here as a bindings and an application developer, not as a Clutter developer). 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). Cheers, Guillaume [1] http://live.gnome.org/PAF ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, Apr 21, 2008 at 10:03 AM, Adam Schreiber [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 10:08 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) Unless you're writing a book or website where high ranking games of chess are recreated and commented on. Not that I want to do that, just a counter example. Since the existing high-resolution 2D Cairo engines are still present and their code is being reused for the accelerated version, there's no need to worry about the deprecation of 2D. We all understand the value of 2D and we aren't going to be carving it out any time soon. Not until--at least--the far future when we're at war with talking badgers... (How's that for straying from the subject!) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, Apr 21, 2008 at 10:08 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) Unless you're writing a book or website where high ranking games of chess are recreated and commented on. Not that I want to do that, just a counter example. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
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
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
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.
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Il giorno lun, 21/04/2008 alle 17.10 +0100, Emmanuele Bassi ha scritto: On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: 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]. Emmanuele, IMHO the better and faster way to show everyone the Clutter goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 weeks ;-) [1] http://www.apple.com/itunes/jukebox/coverflow.html [2] if you want a bonus, provide both docked and fullscreen mode signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On 21 Apr 2008, at 20:37, Luca Ferretti wrote: Il giorno lun, 21/04/2008 alle 17.10 +0100, Emmanuele Bassi ha scritto: On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: 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]. Emmanuele, IMHO the better and faster way to show everyone the Clutter goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 weeks ;-) And then try to find anyone who actually finds it more useful than what was there before :P Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
hi! * clutter could bring some bling into many gnome applications * clutter did a nice job in the last months and provides a usable interface * clutter is already known in gnome-related projects and therefore would not necessarily mean something totally new +1 daniel On Sun, 2008-04-20 at 16:36 -0500, Jason D. Clinton wrote: Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
+1 for inclusion, i even would like to use it in GNOME Scan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, 2008-04-20 at 16:36 -0500, Jason D. Clinton wrote: Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. If Clutter is built on top of opengl exclusively (correct me if I'm wrong), then: 1. It does not use Cairo; 2. It might not work if opengl is not available; 3. It might not integrate nicely with gtk+ printing; Maybe these concerns don't apply to gnome-games. However, Gnome applications in general should be concerned about them IMHO. On the other hand, Cairo has failed to live up to the promise of hardware acceleration. After years of development with no significant results on the hardware acceleration front (when compared to pure OpenGL) perhaps it deserves this fate... Not taking sides here, just providing some comments. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Hello! Pigment should be taken into account and not be dropped because it's Python-only since it is not. Here is a C example of a Cairo sphere rendered on a Pigment drawable: https://code.fluendo.com/pigment/trac/browser/trunk/pigment/examples/sphere.c Have a nice day, Florian On Sun, 2008-04-20 at 16:36 -0500, Jason D. Clinton wrote: Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. ___ 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
