|
Hi, I have a few questions regarding how to get the patchset accepted to update cluttermm. The first is will it happen? I've had a large amount of silence after the initial review. Second, I'm uncertain how much work I'd have to do to make it possible. Murray's comments on the bug (at this bugzilla address- bug 725125 suggest I'd have to isolate all the elements belonging to each class/ set of classes to get the patchset approved. In particular, to identify the clutter_methods.defs/ clutter_signals.defs changes required for each file would mean manually going through the generated defs files and isolating the changes for each set of components. For each new .hg file I'd also have to add the diff for the codegen/m4/convert_clutter.m4 file, the codegen/generate_extra_defs.cc file, the src/clutter/filelist.am file, as well as the changes in downstream classes (Clutter::Actor in particular) that rely on the new class. Third, I've now got the complex animation framework functioning, and writing the example/ test cases identified some problems with the wrapper that I've fixed. Should I add this as another patch to apply after all the previous ones, or redo the patchset so that this is incorporated in the original diff? Finally, a policy question. The complex animation framework uses the Interval class, which in C has a constructor with the following signature: ClutterInterval * clutter_interval_new (GType gtype, ...); and an alternate for wrapping libraries of ClutterInterval * clutter_interval_new_with_values (GType gtype, const GValue *initial, const GValue *final); What I propose is to wrap numeric values in the Clutter::Interval class to allow the following: static Glib::RefPtr< Interval > create (const int initialv, const int finalv) static Glib::RefPtr< Interval > create (const double initialv, const double finalv) static Glib::RefPtr< Interval > create (const float initialv, const float finalv) while keeping the Glib::Value constructor to allow use of other types if required: static Glib::RefPtr< Interval > create (GType value_type, const Glib::ValueBase& initialv, const Glib::ValueBase& finalv) From a usability point of view, I find Glib::Values poxy- they require that you know the GType before you construct one, so you have to expose the type to the end-user. However, in this context the type of values required are all Clutter::Actor properties, and these fall into 3 groups. Most are numeric (either int, float or double); some are Clutter classes (e.g. color), and then a number are bool or enums. Given that this is for an animation framework, animating a bool or enum value is an oxymoron. Is it acceptable to overload the create() method to allow ease of use of the common numeric types? Ian. |