I'm trying to wrap the animation classes in Cluttermm.
Clutter::Animation is the basic animation class. It's got a restricted interface- for instance it only animates one object, and the start and finish times are the only two points where an actor's location can be defined.
In the C code it's used for simple animations, but accessed through clutter_actor_animate, and there's a bit of initialisation that happens in there that doesn't happen in the class constructor. In particular, the Timeline is initialised beside the Animation, not inside it.
What that seems to mean is that wrapping the Animation class has unexpected issues. The code below has a problem:
/*a bit of initialisation above this*/
Glib::RefPtr<Clutter::Animation> animation = Clutter::Animation::create();
//only way to get the animation's timeline:
const Glib::RefPtr<Clutter::Alpha> my_alpha =
const Glib::RefPtr<Clutter::Timeline> tl =my_alpha->get_timeline();
tl->set_duration(3000); /*this should be sufficient */
//bind a value:
//bind with a start and a finish value:
animation->bind_interval("opacity", 0, 255);
//start the timeline:
// Start the main loop:
If I compile the above, it works (I've had to wrap the bind() methods first- that's this bug report ). If I comment out the animation->set_duration(), it segfaults; I think it's probably because the Timeline isn't properly initialised in the Animation class init().
1) is it worth fixing this for a basic interface that's unlikely to get much use?
2) The issue for Cluttermm is that clutter_actor_animate hasn't been wrapped, so is it a better option to wrap the clutter_actor_animate function, and hide the Animation class from the user (as currently happens in C)?
3) I think it's due to the way the C code uses ClutterAnimation, not a problem with the C++ wrapper. Given the code above, does that make sense?
4) A general wrapping question. All the functions I'm having to wrap manually can take any value, and in C they convert it to a GValue. For animations there's no point taking non-numeric values ( there's no intrinsic way to increment a string value, for instance) so if the value is non-numeric it shouldn't be accepted as input. Is it reasonable to screen for that in the function wrapper?