Re: [clutter] ClutterColor API bindings questions
Maybe the C API is more useful in C because you more often have direct access to color instance. For instance, maybe you would do something like this: clutter_color_darken(default_color, thing-color); redraw_thing(thing); But in C++ we will tend to do copy-by-value instead of allowing that direct access. I suggest that we stick to color.darken(); for now, and add more efficient versions later if necessary. By the way, this particular function is rather strange to me. It Darkens src by a fixed amount, and saves the changed color in dest, but I wonder when I would ever want to darken by some unknown unspecified amount. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Pages missing from online API reference
On Fri, 2007-10-26 at 11:40 +0100, Matthew Allum wrote: Should now be fixed (with thanks to you and Mr Bassi) Thanks, but here is another one: This page http://clutter-project.org/docs/clutter-ClutterStage.html links to here: http://clutter-project.org/clutter/ClutterStage.html which does not exist. It should probably link to itself. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter_label_new_full const params
On Wed, 2007-11-07 at 18:18 +0100, Gwenole Beauchesne wrote: On Wed, 7 Nov 2007, Emmanuele Bassi wrote: Should the third param be '_const_ ClutterColor *color'? It's defined as const in clutter_label_set_color(), so I would expect it to be the same in the constructor. yes, it should be a const, at least for consistency. Oh oh, I was exactly thinking about it yesterday though I have not submitted a patch yet because there are some other locations where constification is desirable. Well, only pango layout stuff but are they meant to be public API? Watch out, though. const doesn't work well in C, because C has no mutable keyword, and no const/non-const method-overloading for getters. It's only useful for simple structs such as ClutterColor. Jonathon, can you please open a bug on clutter's bugzilla product at: http://bugzilla.openedhand.org/enter_bug.cgi?product=Clutter BTW, the new Bugzilla look is nicer. ;-) -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Creating a scrolled list
I remember seeing an iTunes-ish demo at GUADEC, showing a track listing in a window. I think it scrolled. Is there some code I can look at for that or something similar, to see how you implemented that? What's the general plan with these higher-level building blocks in clutter? You already have ClutterEntry. Do you plan to add buttons, menus, etc, or do you plan to make regular GTK+ widgets appear less alien as clutter actors? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Creating a scrolled list
On Tue, 2007-11-13 at 15:38 +, Matthew Allum wrote: Hi; On Tue, 2007-11-13 at 16:21 +0100, Murray Cumming wrote: I remember seeing an iTunes-ish demo at GUADEC, showing a track listing in a window. I think it scrolled. Is there some code I can look at for that or something similar, to see how you implemented that? That was a demo to test the clutter API and essentially see how far we could push things and how long completely copying something like coverflow would take. We're kind of wooses when it comes to making it public-ally available as it is such a blatant and exact copy of Apples cover flow. Its unclear if it patented but we dont want to attract the wrong kind of attention and ultimately though it looks and acts very cool its just a boring unoriginal 'me too' rip off. Maybe you could just rip out the scrolling window part of the code? It seems like a common task so it would be useful example code. What's the general plan with these higher-level building blocks in clutter? You already have ClutterEntry. Do you plan to add buttons, menus, etc, or do you plan to make regular GTK+ widgets appear less alien as clutter actors? The general idea is to keep clutter itself quite raw/generic but still useful and flexible - rich canvas like. The expectation is that higher level toolkits would be written quickly and easily on top that fit a specific UI's/devices need. For the kind of user interfaces clutter is aimed at I dont think a high level one size fits all approach is possible. OK, so I guess I hope that people put these things into a separate library for reuse. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] 2.5D?
Clutter is a 2.5D canvas, right? I mean, it can contain 2D objects that can have some extruded depth, and which can move in 3D space. But it can't have, for instance, a pyramid object? Maybe I'm even wrong about the extruded depth. Does clutter_actor_set_depth() set the z position of the object or the z dimension of the object? Is this a limitation of OpenGL ES, or just a design decision for Clutter? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] 2.5D?
On Wed, 2007-11-14 at 12:17 +, Matthew Allum wrote: Hi; On Wed, 2007-11-14 at 12:55 +0100, Murray Cumming wrote: Clutter is a 2.5D canvas, right? I mean, it can contain 2D objects that can have some extruded depth, and which can move in 3D space. But it can't have, for instance, a pyramid object? Yes and no. Everything is in 3D space but the API is heavily slanted towards more 2D usage (kind of 2D with 3D effects). Actors are essentially 2D quads but positionable / rotate-able in 3D space. You could however make an actor that was a pyramid (by dropping into raw GL). It would however be a bit cludgy with current API in wider scope (but potentially could be extended if the need is there). Maybe I'm even wrong about the extruded depth. Does clutter_actor_set_depth() set the z position of the object or the z dimension of the object? Z position. Maybe we should rename this and actually make depth a kind of volume like prop (or drop it). Would that seem more logical ? I think so yes. It should at least be made clearer in the API documentation for that function. Is there any actual way to set an extruded depth then, or do actors now have zero depth? For instance, can I ever see anything on screen if I rotate a rectangle so only its edge is facing me? I've been a bit concerned about doing this in the past as having a set_z could kind of make people think Clutter really is a general 3D engine kind of thing. That also just needs to be stated clearly, I think. For the uninitiated it's not immediately clear that that's what all these iPhoneish UIs have in common. Is this a limitation of OpenGL ES, or just a design decision for Clutter? Design decision. If you start really heavily supporting 3D its really difficult to keep things simple as well as Im not heavily convinced that full full 3D really buys you much UI wise beyond crazed 1980's neuromancer style things I tend to agree. I just didn't see this strategy from the start. Hope that helps in explaining things; Thanks. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] clutter_actor_request_coords() unclear
The documentation for clutter_actor_request_coords() is unclear to me. What data is it giving me and how is it giving it to me? Is the box parameter an output (or in/out) parameter? http://clutter-project.org/docs/ClutterActor.html#clutter-actor-request-coords Likewise, clutter_actor_query_coords(), which has the extra confusion that I need to wonder what is the difference between new untransformed co-ordinates and untransformed co-ordinates. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] 2.5D?
On Wed, 2007-11-14 at 12:17 +, Matthew Allum wrote: Im not heavily convinced that full full 3D really buys you much UI wise beyond crazed 1980's neuromancer style things What, the future is cancelled? Has popular culture been lying to me? Those bastards. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Pages missing from online API reference
On Fri, 2007-10-26 at 11:40 +0100, Matthew Allum wrote: Should now be fixed (with thanks to you and Mr Bassi) I also notice that the documentation doesn't show the object hierarchy. For instance ClutterStage derives from ClutterGroup and then from ClutterActor, but that's not shown here: http://www.clutter-project.org/docs/clutter-ClutterStage.html In my regenerated documentation I do see it: http://www.openismus.com/temp/clutter_api_html/ClutterStage.html#ClutterStage.object-hierarchy Is the online documentation wrong or wildly out of date, or is the svn API just very different to the last tarball? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Pages missing from online API reference
On Thu, 2007-11-15 at 12:32 +, Matthew Allum wrote: On Thu, 2007-11-15 at 13:19 +0100, Murray Cumming wrote: Is the online documentation wrong or wildly out of date, or is the svn API just very different to the last tarball? The web site documentation should be for the last (0.4.x) stable release. SVN trunk is effectively what will be the 0.6 release and thus it will have API/ABI breakage (like gstreamer different versions can be parallel installed) and different docs. Or do you refer to the stable 0.4 branch in svn ? I mean trunk, sorry. I just didn't expect such a change since 0.4. I'll just use my regenerated documentation. Thanks. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clutter-trunk widget event handlers
I am also having problems with actor signals. I get the button-press and
button-release signals, but not, for instance, the motion-event,
enter-event and leave-event signals.
I attached my simple test code. I don't see an obvious error.
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
/* Copyright 2007 Openismus GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2
* as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include clutter/clutter.h
#include stdlib.h
static void
on_stage_button_press (ClutterStage *stage, ClutterEvent *event, gpointer data)
{
gint x = 0;
gint y = 0;
clutter_event_get_coords (event, x, y);
g_print (Clicked stage at (%d, %d)\n, x, y);
/* Discover whether there is an actor at that position.
* Note that you can also connect directly to the actor's signals instead.
*/
ClutterActor *rect = clutter_stage_get_actor_at_pos (stage, x, y);
if (!rect)
return;
if (CLUTTER_IS_RECTANGLE (rect))
g_print ( A rectangle is at that position.\n);
}
static void
on_rect_button_press (ClutterRectangle *rect, ClutterEvent *event, gpointer data)
{
gint x = 0;
gint y = 0;
clutter_event_get_coords (event, x, y);
g_print (Clicked rectangle at (%d, %d)\n, x, y);
/* clutter_main_quit(); */
}
static void
on_rect_button_release (ClutterRectangle *rect, ClutterEvent *event, gpointer data)
{
gint x = 0;
gint y = 0;
clutter_event_get_coords (event, x, y);
g_print (Click-release on rectangle at (%d, %d)\n, x, y);
}
static void
on_rect_motion (ClutterRectangle *rect, ClutterEvent *event, gpointer data)
{
g_print (Motion in the rectangle.);
}
static void
on_rect_enter (ClutterRectangle *rect, ClutterEvent *event, gpointer data)
{
g_print (Entered rectangle.);
}
static void
on_rect_leave (ClutterRectangle *rect, ClutterEvent *event, gpointer data)
{
g_print (Left rectangle.);
}
int main(int argc, char *argv[])
{
ClutterColor stage_color = { 0x00, 0x00, 0x00, 0xff };
ClutterColor label_color = { 0xff, 0xff, 0xff, 0x99 };
clutter_init (argc, argv);
/* Get the stage and set its size and color: */
ClutterActor *stage = clutter_stage_get_default ();
clutter_actor_set_size (stage, 800, 600);
clutter_stage_set_color (CLUTTER_STAGE (stage), stage_color);
/* Connect signal handlers to handle mouse clicks and key presses on the stage: */
g_signal_connect (stage, button-press-event,
G_CALLBACK (on_stage_button_press), NULL);
/* Add a Rectangle to the stage: */
ClutterActor *rect = clutter_rectangle_new_with_color (label_color);
clutter_actor_set_size (rect, 100, 100);
clutter_actor_set_position (rect, 50, 50);
clutter_actor_show (rect);
clutter_container_add_actor (CLUTTER_CONTAINER (stage), rect);
clutter_actor_set_reactive (rect);
g_signal_connect (rect, button-press-event,
G_CALLBACK (on_rect_button_press), NULL);
g_signal_connect (rect, button-release-event,
G_CALLBACK (on_rect_button_release), NULL);
g_signal_connect (rect, motion-event,
G_CALLBACK (on_rect_motion), NULL);
g_signal_connect (rect, enter-event,
G_CALLBACK (on_rect_enter), NULL);
g_signal_connect (rect, leave-event,
G_CALLBACK (on_rect_leave), NULL);
/* Show the stage: */
clutter_actor_show (stage);
/* Start the main loop, so we can respond to events: */
clutter_main ();
return EXIT_SUCCESS;
}
Re: [clutter] Clutter-trunk widget event handlers
On Thu, 2007-11-15 at 13:34 +, Matthew Allum wrote: You need to call clutter_enable_motion_events (); - its a performance opt that maybe needs to work the other way around (be explicity disabled rather than enabled). Thanks. I guess that this (and clutter_actor_set_reactive()) should be mentioned in the documentation for these signals. Note the new event stuff in trunk is heavily in flux, thats why its not documented yet (it still could change heavily). Also could you start using bugzilla for these kind of things, it much easier for us to track/manage that way. OK. I didn't think of them as bugs yet, but I'll do that. Thanks again. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clutter knot?
On Fri, 2007-11-16 at 17:12 +, Emmanuele Bassi wrote: On Fri, 2007-11-16 at 17:45 +0100, Murray Cumming wrote: Is there any particular reason that ClutterKnot isn't called ClutterPoint, which is what it appears to be? it's a knot in a path, which is why the ClutterKnot structure was created in the first place. Emmanuele told me on irc that this is standard terminology for B-splines: http://en.wikipedia.org/wiki/B-Spline I don't know why a point on a path is called a knot, but I won't worry about it too much. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Clutter knot?
Is there any particular reason that ClutterKnot isn't called ClutterPoint, which is what it appears to be? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clutter tutorial and a clutter_behaviour_ellipse_set_angle_end() problem
On Fri, 2007-12-07 at 14:16 +, Matthew Allum wrote: On Fri, 2007-12-07 at 15:07 +0100, Murray Cumming wrote: On Fri, 2007-12-07 at 14:53 +0100, Murray Cumming wrote: For Openismus, I have started a tutorial to cover Clutter and to mention a little about other libraries such as clutter-gtk and clutter-cairo and maybe clutter-gst. I should have it finished in a week or so, and I'll then keep it up to date with the API changes. HTML of its current state is here: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/index.html By the way, I should make clear that this is unfinished and is not yet a good way to learn Clutter. I'm posting it so that people who already know Clutter can tell me how wrong it is. Cool stuff. Some quick notes from me (I will provide better feedback/patches when I have more time). - It doesn't say which version of clutter it targets ? I would base it on 0.6 (i.e trunk), there should not be that much API churn now before release (Hopefully Jan). - In terms of '2.5D' - essentially clutter actors are 2D layers which can be positioned and transformed in full 3D space. - I would explain effects before behaviours. They are much easier to grasp. Thanks. I'll make some changes. - Are you set on the current visual styling ? No, it's just the CSS I used for the maemomm tutorial, which was in turn based on the gtkmm tutorial. It can easily be changed. What should I mimic? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] ClutterBehaviourEllipse: angles 359
What is the intended meaning of angles of 360 degrees or more with ClutterBehaviourEllipse? For instance, I see that a clockwise ellipse with a start angle of 360 and end angle of 90 causes an item to move through 360 and then an extra 90, though I'd expect it to just move 90 degrees. I could see the sense of moving through 360 degrees if the end angle was larger than the start, or if I was moving anti-clockwise, but the current behaviour seems odd. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Tutoral: Ways to use OpenGL directly
In the tutorial, I have a chapter about implementing actors. Of course, I'm mentioning the OpenGL API there because you'd have to draw the actor somehow. I mention cogl too but I think OpenGL will be necessary in most cases. I wonder if this is the only/best way to use OpenGL directly. Maybe I don't need the separate Using OpenGL appendix. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] unrefing Timelines and Behaviours.
On Fri, 2007-12-14 at 10:49 +, Emmanuele Bassi wrote: On Thu, 2007-12-13 at 19:48 +0100, Murray Cumming wrote: So this is a question for the Clutter developers. Are we really meant to connect to ClutterTimeline's completed signal just so we can unref the timeline and any behaviours that are used by that timeline? well, yes and no: - if you want to destroy the behaviour as soon as the timeline is complete, connect to the ClutterTimeline::completed signal and unref the behaviour there - if you want to do manual garbage collection, just reuse the timelines and behaviours throughout you application and destroy them when quitting the timeline and behaviour classes are meant to be reusable. ClutterAlpha instances have a floating reference, Ah, I missed this. I'll update that part of the tutorial. because they don't mean anything if now bound to a behaviour; the alpha objects keep a reference on the timelines as well, so: timeline = clutter_timeline_new_for_duration (1000); alpha = clutter_alpha_new_full (timeline, clutter_alpha_ramp_inc, NULL, NULL); g_object_unref (timeline); behaviour = clutter_behaviour_opacity_new (alpha, 0, 255); will make the timeline disappear as soon as the behaviour is disposed, so you have to keep a single object around; to retrieve the timeline from the behaviour, Great. I guess I wasn't seeing this because I was doing an unnecessary extra unref of the alpha. just get the alpha from the latter and from the alpha get the timeline: timeline = behaviour.get_alpha().get_timeline() By the way, I don't really see the point of ClutterAlpha in the public API, unless you are planning to add more functions to it. At the moment it seems like behaviours could just take the alpha callback, and that alpha callback could receive the timeline as a parameter, instead of getting it from a ClutterAlpha. This seems to be necessary at the moment. Currently, unrefing either the timeline or the behaviours before completion will stop the behaviour from happening. yes, because the behaviours and the timelines are top-level objects, like ClutterScript, ClutterScore and ClutterModel. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clutter tutorial and a clutter_behaviour_ellipse_set_angle_end() problem
On Fri, 2007-12-14 at 13:38 +, Matthew Allum wrote: Hi; Attached are some rough notes for documentation Im half way through, which hopefully clear up some things and give clarity to some features. Wanted to spend a bit more time on this before submitting but getting worried as to attention tutorial is seeking when in such an earlier state - i.e it could cause more confusion than good. Thanks. Some of the phrasing is useful, but most of this seems to be mentioned already. I don't understand which bits are intended as corrections or additions. I didn't realize that more feedback was on the way so quickly, so I thought I'd blog it to get some, but I don't think the explanations are hopelessly wrong at the moment. Also I would strongly recommend (if not already) you try and create a medium size clutter application as to more understand why parts of the API are the way they are. Yeah, that's the intention of the (currently ugly) full example, though it will never be a real application. It's delaying further work on that until the new high-level library exists. I'm sure to still disagree with one or two tiny things, but that's OK. Things like timelines, behaviours etc went through many iterations of design and practical use before settling on what they currently are. (Not meaning to sound non appreciative here btw) -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] unrefing Timelines and Behaviours.
On Fri, 2007-12-14 at 11:51 +, Emmanuele Bassi wrote: On Fri, 2007-12-14 at 12:20 +0100, Murray Cumming wrote: By the way, I don't really see the point of ClutterAlpha in the public API, unless you are planning to add more functions to it. At the moment it seems like behaviours could just take the alpha callback, and that alpha callback could receive the timeline as a parameter, instead of getting it from a ClutterAlpha. no, we need to expose the ClutterAlpha API because the same ClutterAlpha can be reused with multiple behaviours: timeline = clutter.Timeline(duration=1000) alpha = clutter.Alpha(timeline, clutter.ramp_inc_func) pathb = clutter.BehaviourPath(alpha, knots) depthb = clutter.BehaviourDepth(alpha, -100, 100) [b.apply(my_actor) for b in (pathb, depthb)] will share the same alpha, hence the same timeline and the same function of time. this would become needlessly complicated if we passed the same function and then the same timeline, for instance (fantasy code, it will not be implemented): timeline = clutter.Timeline(duration=1000) pathb = clutter.BehaviourPath(timeline, clutter.ramp_inc_func, knots) depthb = clutter.BehaviourDepht(timeline, clutter.ramp_inc_func, -100, 100) I actually prefer this public API (and for effects too), but I guess it's just a personal preference. Thanks anyway. [b.apply(my_actor) for b in (pathb, depthb)] which will make the source one line shorter, but will add a function argument to the behaviours and will require the following API additions: clutter_behaviour_get_timeline() clutter_behaviour_set_timeline() clutter_behaviour_set_alpha_function() personally, I prefer keeping the behaviours blissfully unaware of what a timeline is: I can see how that would be good for the implementation. the time+function aspect is covered by the alpha class, which in turn can be used to drive other non-behaviour objects without requiring additions or changes. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Re: Event handling chain
On Mon, 2007-12-17 at 11:06 +, Matthew Allum wrote: On Mon, 2007-12-17 at 11:31 +0100, Murray Cumming wrote: On Fri, 2007-12-14 at 13:38 +, Matthew Allum wrote: Input events are handled initially by the stage the event will enter a capture phase continue down through children to the 'source' actor of the event (for example the actor that was clicked on) before then entering the 'bubble' phase going back up through parents to the stage. Does this really meant that the stage gets two chances to handle an event? Yes. It is like the W3 event model. So if I return false from my signal handler for the stage then that same handler will be called a second time? No - well not unless you've attached the same handler to both signals. I thought we were talking about one signal, so I don't understand. What two signals might you mean here, for example? The event can be stopped at any stage by an actor in the event pipeline. By the way, this return true to stop further signal handling really should be in the API reference for each signal. Agreed - Ebassi ? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Problem with new ClutterActor definition
On Wed, 2008-01-30 at 18:10 +, Matthew Allum wrote: Hi; On Wed, 2008-01-30 at 17:35 +0100, Murray Cumming wrote: On Wed, 2008-01-30 at 16:32 +, Matthew Allum wrote: Hi; On Wed, 2008-01-30 at 17:07 +0100, Matteo Cappadonna wrote: I have followed this tutorial: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/apa.html Just as a quick note for folks, please take care in following that tutorial. Its not complete, contains some inaccuracies Please do find the time to tell me about inaccuracies. Until now I've corrected everything that you've mentioned. Will definitely do so! Its not so much total inaccuracies in API usage etc its just I think it misses detail where its important and feels quite dry (e.g. no diagrams) / impractical (animation stuff is not totally clear) - just a rather thin extension of the API docs The API documentation is rather bare. Much of the stuff in the documentation could indeed be in the API documentation. with some not so exciting examples As the documentation states, the examples are meant to be very simple so that the new concepts are obvious and not lost in a sea of code. The full example should indeed be much more exciting (it's crappy) and I hope that someone with more clutter-foo will one day do that. and rather strange descriptions (2.5D for example, '2D surfaces in 3D space' is better imho). Changed. I picked 2.5D up from somewhere or other and it seemed to be the one that Clutter people liked and understood. It was new to me. Anyway dont take that the wrong way - I know it is not easy to write docs. Am likely going to write a 'chapter' on animation so I can show you what I mean. and is not totally in sync with current trunk. It should be. The examples build against trunk (they aren't just copy/pasted in). From a quick look, I dont think the events and actor docs (event capture phase, I updated the events documentation after the previous discussion on the list. See, for instance, the Clutter first allows the stage to handle each event via the captured-event signal text here: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/ch04s04.html If something else has changed since then about events then I can't see it in the ChangeLog. anchor point, order of transformations etc). What part of the API should I be looking at to mention the anchor point concept, and where is an order of transformations to be discovered? I don't think they are mentioned at all yet in the tutorial. I think GTK widget has had its namespace changed. Thanks. Fixed. GtkClutter changed to GtkClutterEmbed. (and doesn't work any more for me, unfortunately: ) I regularly rebuild clutter and clutter-documentation, but I guess I forgot to rebuild clutter-gtk. Also no info on new features of upcoming 0.6 - JSON, Shaders etc. I'm waiting for someone with more clue than me to provide some kind of example. The lack of these new features in the tutorial doesn't make the tutorial bad though. Other missing stuff (already marked by TODO) is waiting for the high-level library (with boxes, scroll window, etc) to be released so I can take something reasonable sensible as inspiration. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Tutorial stuff to do
On Wed, 2008-01-30 at 18:10 +, Matthew Allum wrote: [snip] Its not so much total inaccuracies in API usage etc its just I think it misses detail where its important and feels quite dry (e.g. no diagrams) / impractical (animation stuff is not totally clear) [snip] I saw that the API reference now has some diagrams, which seem quite useful: http://clutter-project.org/docs/clutter/0.6/ClutterActor.html#id2626353 http://clutter-project.org/docs/clutter/0.6/ClutterAlpha.html#id2648426 http://clutter-project.org/docs/clutter/0.6/ClutterBehaviour.html#id2651362 Would you like me to copy these into the relevant tutorial chapters? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] [ANNOUNCE] Tidy - Bringing order in Clutter
On Fri, 2008-02-22 at 16:41 +0100, Murray Cumming wrote: Is there any plan to add an equivalent for the old ClutterBox, ClutterVBox and ClutterHBox containers? http://clutter-project.org/docs/clutter-ClutterBox.html And may I this old code as the basis for a custom container example in the tutorial? I'd like the examples to be public domain licenced. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Porting from ClutterLayout (0.4) to 0.6
On Sat, 2008-02-23 at 13:48 +0100, Murray Cumming wrote: On Fri, 2008-02-22 at 16:41 +0100, Murray Cumming wrote: Is there any plan to add an equivalent for the old ClutterBox, ClutterVBox and ClutterHBox containers? http://clutter-project.org/docs/clutter-ClutterBox.html And may I this old code as the basis for a custom container example in the tutorial? I'd like the examples to be public domain licenced. I'm going ahead with this in the hope that it will be OK. Clutter*Box in 0.4 implements the child positioning by implementing the ClutterLayout interface. http://svn.o-hand.com/view/clutter/branches/clutter-0-4/clutter/clutter-hbox.c?rev=1328view=markup That has been removed in Clutter 0.6. TidyFrame seems like the simplest example so far for the new way of doing things with Clutter 0.6. It seems to position its child during the ClutterActor::request_coords() implementation. http://svn.o-hand.com/view/tidy/trunk/tidy/tidy-frame.c?rev=105view=markup Is this the generally recommended way to do things with 0.6, or am I not seeing some more explicit mechanism? Is there a 0.4-0.6 porting document somewhere that covers this already? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Porting from ClutterLayout (0.4) to 0.6
On Mon, 2008-02-25 at 14:26 +, Emmanuele Bassi wrote: TidyFrame seems like the simplest example so far for the new way of doing things with Clutter 0.6. It seems to position its child during the ClutterActor::request_coords() implementation. http://svn.o-hand.com/view/tidy/trunk/tidy/tidy-frame.c?rev=105view=markup it repositions its children when adding it (in the override for the ClutterContainer::add virtual function) and when being requested a new bounding box. Is this the generally recommended way to do things with 0.6, or am I not seeing some more explicit mechanism? there is no more explicit mechanism: you want a layout to recompute the position of its children when actually adding the children and when being asked to resize itself. this did not change between 0.4 and 0.6. Thanks. I have written up the basics of implementing a layout container in 0.6 here: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/apas03.html With a very simple HBox-like example: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/apas04.html I would really appreciate it if you could review that and tell me about whatever errors I've (surely) made. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Multi-line text entry
Has anyone implemented multi-line text entry anywhere? (ClutterEntry is single line). I'd like to steal some code for the tutorial. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Are C++ bindings still alive?
On Thu, 2008-04-10 at 13:44 -0500, Jonathon Jongsma wrote: On Thu, Apr 10, 2008 at 1:30 PM, Giacomo Graziosi [EMAIL PROTECTED] wrote: It's still me. This time I'm asking some infos on C++ bindings. Looks like they are in worst conditions than Ruby's ones. Maybe I should focus on some other language right now rather than hoping to use my favourite languages :-). -- To unsubscribe send a mail to [EMAIL PROTECTED] They're not dead, but I'm afraid that they've been on the back burner for a while as I (and others) work on other projects. I hope to get time to work on them again in the future, but for now they're still somewhat incomplete. I think they are in quite good shape. They are far from dead and never were close to dead. We could use some more examples. I wanted to translate my Clutter tutorial to C++ but I'm still hoping that the C people will do a review of that first. Please do file bugs or patches if you discover problems. cluttermm is a component under gnomemm in bugzilla: -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Are C++ bindings still alive?
On Thu, 2008-04-10 at 13:44 -0500, Jonathon Jongsma wrote: On Thu, Apr 10, 2008 at 1:30 PM, Giacomo Graziosi [EMAIL PROTECTED] wrote: It's still me. This time I'm asking some infos on C++ bindings. Looks like they are in worst conditions than Ruby's ones. Maybe I should focus on some other language right now rather than hoping to use my favourite languages :-). -- To unsubscribe send a mail to [EMAIL PROTECTED] They're not dead, but I'm afraid that they've been on the back burner for a while as I (and others) work on other projects. I hope to get time to work on them again in the future, but for now they're still somewhat incomplete. I think they are in quite good shape. They are far from dead and never were close to dead. We could use some more examples. I wanted to translate my Clutter tutorial to C++ but I'm still hoping that the C people will do a review of that first. Please do file bugs or patches if you discover problems. cluttermm is a component under gnomemm in bugzilla: http://bugzilla.gnome.org/browse.cgi?product=gnomemm -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Tutorial review?
I'm still hoping that some Clutter developers can find time to review the clutter tutorial: http://www.openismus.com/misc/clutter_tutorial/docs/tutorial/html/index.html Presumably it's waiting on that review before you consider it part of the official Clutter documentation. If that isn't going to happen then I'll eventually just place it at a more permanent URL at openismus.com. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] ANNOUNCE: cluttermm 0.5.1
cluttermm provides a C++ API for Clutter (a 3D canvas and items), for use with gtkmm. It is usable, and we'd like to hear about any problems or about anything that is missing. Changes: 0.5.1: * Added cluttermm-gtk, wrapping clutter-gtk. This provides the Clutter::Gtk::Embed widget. (Siavash Safi) * Added cluttermm-cairo, wrapping clutter-cairo. This provides Clutter::Cairo::CairoTexture. (Jonathon Jongsma) * Changed the pkg-config files to use 0.6 in their name, so we can target specific clutter API versions. For instance, cluttermm-0.6, cluttermm-gtk-0.6, and cluttermm-cairo-0.6. (Jonathon Jongsma) * Actor: add default value of 'true' to Actor::set_reactive(). (Jonathon Jongsma) Details: We should really put this on a web page: svn: svn.gnome.org/gnomemm/cluttermm/trunk/ http://svn.gnome.org/viewvc/gnomemm/cluttermm/trunk/ (It's in jhbuild) download: http://ftp.gnome.org/pub/GNOME/sources/cluttermm/ submit bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=gnomemmcomponent=cluttermm view bugs: http://bugzilla.gnome.org/buglist.cgi?query=component%3Acluttermm+product%3Agnomemm+ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cluttermm pure?
On Sat, 2008-06-14 at 22:41 +0200, Daniel Oberhoff wrote: Hi is it possible to build cluttermm without cluttergtk? why does it need gtk? I guess we thought we were making life easier and didn't think of non-GTK+ platforms. i cant use cluttergtk on osx, so i would like just cluttermm for clutter, not gtk. is it possible? I guess we should move it into a clutter-gtkmm library. CCing gtkmm-list for other opinions. In the short term, you can probably just hack clutter-gtk out of the build files. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cluttermm pure?
On Sun, 2008-06-15 at 19:31 +0200, Daniel Oberhoff wrote: , wouldnt it make sense simply to have it a configure option to embedd gtk (also cairo)? I find it simpler to split libraries up in separate tarballs rather than make some parts optional. Distros (Linux or whatever) tend not to split them up into separate packages otherwise, leaving you with much the same problem as before. Then, if requested build separate library binaries for cluttermm-gtk and cluttermm-cairo, and copy the appropriate headers only. In the short term, you can probably just hack clutter-gtk out of the build files. Think I'll rather fix clutter-gtk than mess with autotools :). I'll try to get this done for you, but it might take me a few days to have time. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] clutter build broken
The build from svn seems to be broken: clutter-fixed.c:906: error: redefinition of ‘clutter_qmulx’ clutter-fixed.h:294: error: previous definition of ‘clutter_qmulx’ was here clutter-fixed.c:946: error: redefinition of ‘clutter_qdivx’ clutter-fixed.h:320: error: previous definition of ‘clutter_qdivx’ was here -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cluttermm dependencies
On Wed, 2008-07-09 at 17:32 +0300, Michael Boccara wrote:
Hi,
I saw there was a previous post questioning why cluttermm was dependent
on clutter-gtk.
I will just rephrase this.
Indeed the dependency tree is currently like this:
clutter glibmm
clutter-gtk clutter
gtk
clutter-cairo clutter
cairo
cluttermm clutter
glibmm
clutter-gtk
clutter-cairo
gtkmm
cairomm
I also think that the current cluttermm should be split into cluttermm,
clutter-gtkmm, and clutter-cairomm.
Yes, we will probably do this for cluttermm 0.8.
So the dependency tree should be
something like this:
cluttermm clutter
glibmm
clutter-gtkmm cluttermm
clutter-gtk
gtkmm
clutter-cairomm cluttermm
clutter-cairo
cairomm
I tried tweaking the configure file and some Makefile.in to at least
reduce the cluttermm dependencies, but with no success :-(.
I guess the founders of cluttermm will do it better than me...
We are currently dependent on this so that our project won't be
dependent on gtk and cairo.
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Implementing a new actor via cluttermm
On Wed, 2008-07-09 at 17:37 +0300, Michael Boccara wrote: I am new to the GLib and GObjects world, so my question may sound dumb. Is it possible to implement new subclasses of Clutter::Actor without having to subclass the ClutterActor GObject ? In other words, can we create our own actors using cluttermm only ? It should be. You might be the first person to try it though. However, I recommend waiting for us to update cluttermm to 0.8 first though. We didn't do that yet because it currently depends on other clutter-* libraries that were no available in 0.7/0.8 versions (which I consider to be a rather strange release schedule). I guess we'll have something this week. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cluttermm build
On Sun, 2008-07-13 at 17:31 +0300, Michael Boccara wrote: Murray Cumming wrote: Thoughts ? Is there a problem? I guess my problem comes from the fact that I am using the source tar.bz2 (from http://ftp.gnome.org/pub/GNOME/sources/cluttermm/) and not the svn repository (so my using of the 'repository' term was confusing I admit). In the downloadable archive there is a configure file, Of course. That's entirely normal. You'll find the same in other source tarballs, so you can build with just configure and make. as well as both the .hg and .h, and both the .ccg and .cc files. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cluttermm dependencies
On Sun, 2008-07-13 at 15:55 +0200, Murray Cumming wrote: On Wed, 2008-07-09 at 17:32 +0300, Michael Boccara wrote: I also think that the current cluttermm should be split into cluttermm, clutter-gtkmm, and clutter-cairomm. Yes, we will probably do this for cluttermm 0.8. I'm trying this now. There is one problem. clutter depends on pango, so cluttermm depends on pangomm. But pangomm is not a separate module from gtkmm, though it is a separate shared library. Maybe we can split it out of the gtkmm tarball, but I'll have to think carefully about what that means for API/ABI stability. Also, pangomm depends on cairomm, though pango does not depend on cairo (it depends only on the pango-cairo part of cairo). That's because we did not split cairomm up into cairo-only and cairo-pango parts, to make the C++ API nicer. Hopefully a cairo (and cairomm) dependency is not too bad. What is the big problem with installing gtkmm, by the way? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] ANNOUNCE: cluttermm 0.7.2
cluttermm provides a C++ API for Clutter (a 3D canvas and items), for use with gtkmm. It is usable, and we'd like to hear about any problems or about anything that is missing. Changes: cluttermm, clutter-cairomm and clutter-gtkmm now wrap clutter-0.8, clutter-cairo-0.8 and clutter-gtk-0.8. They still have no been used much, so please do file bugs. Details: We should really put this on a web page: svn: svn.gnome.org/gnomemm/cluttermm/trunk/ http://svn.gnome.org/viewvc/gnomemm/cluttermm/trunk/ (It's in jhbuild) download: http://ftp.gnome.org/pub/GNOME/sources/cluttermm/ submit bugs: http://bugzilla.gnome.org/enter_bug.cgi?product=gnomemmcomponent=cluttermm view bugs: http://bugzilla.gnome.org/buglist.cgi?query=component%3Acluttermm+product%3Agnomemm+ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Box2D: hit detection
Does clutter-box2d offer any way to get a callback when one actor hits another? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Box2D: Actors on a rail?
I have sometimes thought that it would be a nice abstraction to put an actor on a rail and let the user move it along that rail. Does clutter-box2d offer anything like that, or could it? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Errors building clutter
On Mon, 2008-08-11 at 01:40 -0400, David Cummings wrote: Hi all, Thanks for a very neat library. I recently build the SVN version, and had some issues which I figured someone ought to know about. 1. The configure script for clutter-tutorial calls pkg-config to look explicitly for clutter-0.7 and clutter-gtk-0.7, neither of which are installed when building from 0.8. I have just updated the clutter tutorial. Thanks for the reminder. http://www.openismus.com/documents/clutter_tutorial/0.8/docs/tutorial/html/chapter-headers-and-linking.html I just search/replaced and built/ran the examples happily, but this should probably be changed to search for a minimum version of the library. I don't know enough about pkg-config, unfortunately. You want to depend on a specific version of the clutter API, because the different APIs are not compatible. Don't confuse the tarball version (0.8.1, 0.8.3, for instance) with the API version (0.6, 0.7, 0.8, etc). -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Box2D: Actors on a rail?
On Mon, 2008-08-11 at 11:32 +0100, Øyvind Kolås wrote: On Mon, Aug 11, 2008 at 11:03 AM, Murray Cumming [EMAIL PROTECTED] wrote: I have sometimes thought that it would be a nice abstraction to put an actor on a rail and let the user move it along that rail. Does clutter-box2d offer anything like that, or could it? There are multiple ways you could do this. By creating some actors in a box2d group that will not be visualized but only used for the physics simulation. The elastomanic approach would be to create a railing and then a wagon that drives the rail with wheels/sledges on both sides of the railing that are held together by an elastic joint making it snugly hug the railing. Ideally you probably would want to use circular shapes for wheels, but ClutterBox2d is currently only mirroring the bounding boxes of actors making you have to stick with rectangles for now. ___ _ | || | |_|_|| |===|===\ | | | | | \ | |___| \ / \_/ It would also be possible to do it with only one wheel, where you create a hollow railing. For both of these you might have to do some additional tweaking of how the pointer events manipulate the actors since you might want a larger grabbable region than the underlying mechanics would provide. Note that all of this mechanics might be placed in actors that are hidden/have 0 opacity. Many thanks for thinking about it. But I guess this would be a rather inefficient way of getting this behaviour, as well as being lengthy to implement. I guess this is something that could be abstracted outside of clutter-box2d, though it would be nice to still use the hitting and damping stuff from clutter-box22d. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] [bugzilla] copyright waiver for patches
On Mon, 2009-03-30 at 17:51 +0100, Emmanuele Bassi wrote: hi everyone; for legal reasons we now have to ask everyone that attaches a patch for Clutter to our Bugzilla to waive the copyright for the patch itself -- effectively placing the patch under public domain. the full copyright waiver is available at: http://bugzilla.openedhand.com/waiver.html [snip] Will the Clutter license be changing to public domain too? I don't believe a license (LGPL at the moment) can be enforced if there is no copyright holder, and probably not if large parts of the product have no copyright holder. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] [bugzilla] copyright waiver for patches
On Tue, 2009-03-31 at 10:16 +0100, Emmanuele Bassi wrote: On Mon, 2009-03-30 at 21:42 +0200, Murray Cumming wrote: for legal reasons we now have to ask everyone that attaches a patch for Clutter to our Bugzilla to waive the copyright for the patch itself -- effectively placing the patch under public domain. the full copyright waiver is available at: http://bugzilla.openedhand.com/waiver.html [snip] Will the Clutter license be changing to public domain too? obviously not. I don't believe a license (LGPL at the moment) can be enforced if there is no copyright holder, and probably not if large parts of the product have no copyright holder. the patch, in order to be integrated, must be placed under the public domain; once we integrate it in the repository it effectively becomes part of Clutter, hence it falls under its licensing terms. other than that, IANAL -- but the legal team that came up with this option are so I tend to trust their recommendations on legal matters. Yeah, I would normally avoid any boring legal discussion, but I do think it's a fundamental part of copyright law that you can't go to court and defend a copyright if you are not the copyright holder. That concept has some fancy latin name and it's lawyer 101. And a license is meaningless without copyright. I suggest you run that idea by the lawyers. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] [bugzilla] copyright waiver for patches
On Tue, 2009-03-31 at 17:43 +0200, Murray Cumming wrote: Yeah, I would normally avoid any boring legal discussion, but I do think it's a fundamental part of copyright law that you can't go to court and defend a copyright if you are not the copyright holder. That concept has some fancy latin name and it's lawyer 101. And a license is meaningless without copyright. I haven't seen anything that changes my mind about this. I want my code to be under my chosen open source license, not under public domain. Therefore, I'll move the clutter-tutorial to GNOME's git repository and use GNOME's bugzilla, instead of bugzilla.openedhand.com which now asks patch submitters to approve that copyright waiver. The openedhand developers have not made any real effort to review the clutter tutorial anyway, despite my efforts to make it an official part of clutter rather than something outside of clutter/openedhand. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] [bugzilla] copyright waiver for patches
On Thu, 2009-04-16 at 11:49 +0100, Emmanuele Bassi wrote: I think there has been some form of misunderstanding here; the copyright waiver is only needed for the Clutter libraries, not - for instance - for the tutorial. the attachment flag on Bugzilla is entirely optional in nature; otherwise we'd have a disclaimer saying you are waiving your copyright when attaching a patch to Clutter core by pressing 'Submit'. Cool. But that's far from clear when attaching in bugzilla. It just talks about the Clutter Project and strongly suggests that your patch cannot be used if the waiver is not accepted. I'll wait a few days in case someone manages to fix that. As well as making that text clearer, I guess you should try to only show it for relevant products in bugzilla. for external documentation and bindings hosted on clutter-project.org that we don't control (e.g. the clutter-sharp bindings) we cannot ask for a copyright waiver simply because we don't have the copyright on thme -- the copyright of the tutorial is (C) Openismus, not (C) Intel Corporation. also if you don't want to waive your copyright *when contributing to Clutter* then you can contact us and we'll start the loop with the Intel lawyers for other copyright handling options. that's also what I wrote in the original email. The openedhand developers have not made any real effort to review the clutter tutorial anyway, despite my efforts to make it an official part of clutter rather than something outside of clutter/openedhand. I actually read the tutorial, and apart from the general 2.5D/3D issue that was reported, Which was mentioned to me by an openedhand person and was removed as soon as an openedhand person said they didn't like it, but I keep hearing pointless complaints about it even now. the general feeling was that the tutorial just needed some more examples and review from third party developers. Openedhand developers have warned people not to use it until openedhand developers have reviewed it, which they haven't. Sorry for not spending the time to do the email archeology. I speak for myself, but I cannot write a decent tutorial because: a) I know how Clutter internals work, and b) if I have to write some documentation I prefer having it inside the API reference. Thanks. You haven't personally been part of the problem. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] how to solve ClutterFixed_REPLACED_BY_CoglFixed error?
On Fri, 2009-05-08 at 01:55 +0100, Emmanuele Bassi wrote: after I changed ClutterFixed to CoglFixed, and CLUTTER_INT_TO_FIXED to COGL_FIXED_FROM_INT, it output this error message: error: cannot convert ‘CoglFixed*’ to ‘float*’ for argument ‘1’ to ‘void cogl_path_polygon(float*, gint)’ how could i solve it? what's the correct way to do it? thank Cogl API uses floating point, not fixed point types. the tutorial should be fixed to reflect this. The C version of the tutorial is already correct: http://www.openismus.com/documents/clutter_tutorial/0.9/docs/tutorial/html/custom-actor-example.html The cluttermm (C++) version of the tutorial (what this was thread is about) has not yet been updated for the API changes, though I think cluttermm itself is fairly up-to-date. I think we'll wait for the C one to be ready first, maybe waiting for clutter 1.0. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] gst-0.9 example + text actor : bug?
On Mon, 2009-05-18 at 18:45 +0300, Aarto Matti wrote: ClutterActor *test_actor = clutter_text_new_full (Sans 14, argv[1], control_color2); + clutter_container_add_actor(CLUTTER_CONTAINER (stage), *test_actor You are derefencing your ClutterActor* to pass it by value. That should not compile, at least not without compiler warnings. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cluttermm: deriving from Clutter::Texture
On Sun, 2009-06-07 at 12:05 +0200, Bartosz Kostrzewa wrote: Attached is a simple test case which explains what the problem is. The ending of Clutter::main() does not remove actors from the stage. stage-remove_actor(object) has to be called explicitly for the reference count of object to be decremented properly. I would consider this a bug taking into account how dynamic instantiation can be in C++. Can you add this to bugzilla, please? gnomemm/cluttermm in bugzilla.gnome.org. I can't promise to take a look at this particularly soon, but I wouldn't want us to forget about it. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] ANNOUNCE: cluttermm 0.9.5, clutter-gtkmm 0.9.5, clutter-box2dmm 0.9.1
cluttermm provides a C++ API for Clutter (a 3D canvas and items), for use with gtkmm. We'd like to hear about any problems or about anything that is missing. Changes: cluttermm 0.9.5: * Use clutter-1.0 instead of clutter-0.9. (Murray Cumming) * Likewise change our pkg-config file to cluttermm-1.0 instead of cluttermm-0.9, so please change your configure.ac checks too. (Daniel Elstner) * Remove deprecated Actor methods. (Milosz Derezynski) * Use the mm-common build system. (Daniel Elstner) clutter-gtkmm 0.9.5: * Use clutter-gtk-0.10 and cluttermmm 1.0. * Build: - Use mm-common. (Daniel Elstner) - Fix the no-exceptions build. (Milosz Derezynsk) clutter-box2dmm 0.9.1: * Use cluttermm-1.0 and Use clutter-box2d-0.10. * Box2d: - add_distance_joint(): Added default values. - Added explicit get/set_child_*() methods for all the ClutterBox2D child properties. - Used Clutter::Vertex instead of ClutterVertex for all parameters. * Examples: Added examples/distance_joint/ as a simple example of a distance joint. (Murray Cumming) Details: We should really put this on a web page: git: http://git.gnome.org/browse/cluttermm/tree/ (It's in jhbuild) Download: http://ftp.gnome.org/pub/GNOME/sources/cluttermm/ Bugs: https://bugzilla.gnome.org/browse.cgi?product=cluttermm -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Offscreen Clutter Stage
On Tue, 2010-01-05 at 15:49 +, Robert Bragg wrote: If you are interested in the work to migrate parts of the Clutter backends to Cogl so you can track the progress of this work I can look at publishing the crude stabs I've made at this work so far in a branch and perhaps you can provide some feedback on it. That would be great, thanks. People are obviously interested in it. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] ANNOUNCE: cluttermm 1.1.1 and 1.3.1
cluttermm provides a C++ API for Clutter (a 3D canvas and items), for use with gtkmm. We'd like to hear about any problems or about anything that is missing. Changes: cluttermm 1.3.1: (unstable) * Added Action, ActorMeta and Effects. * Actor: - Added add_effect(), remove_effect(), get_effect(). - Added set/set_clip_to_allocation(), contains(), get_has_allocation(), get_accessible(), add_action(), remove_action(), get_action(), clear_actions(). * Stage: Added get/set_no_clear_hint(). * Texture: Added get/set_pick_with_alpha(). (Murray Cumming) cluttermm 1.1.1: (unstable) * Increased the version number to show that we target clutter 1.2, though the cluttermm API is still unstable. (Murray Cumming) * Actor: get_*() methods: Take a reference. (Murray Cumming) * Alpha: get_timeline(): Fixing reference counting. (Chris Kühl) * BehaviourEllipse: Fix the constructor. (Murray Cumming) * BehaviourPath: create_with_knots(): Take a vector instead of the intermediate SListHandle. This is what gtkmm has decided to do in new APIs and happens to solve a memory problem. (Chris Kühl) * Texture: Rename get_amx_tile_waste() to get_max_tile_waste(). (Luca Wehrstedt) * Documentation: - Corrected SlotAlphaFunc documentation. * Build: -Fixed the build with fatal warnings. (Murray Cumming) Details: Documentation: http://library.gnome.org/devel/cluttermm/unstable/ git: http://git.gnome.org/browse/cluttermm/tree/ (It's in jhbuild) Download: http://ftp.gnome.org/pub/GNOME/sources/cluttermm/ Bugs: http://bugzilla.gnome.org/browse.cgi?product=cluttermm -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
