Re: cluttermm update


I think I could spend some time reviewing these patches too, if that
would help; although I'm of course no expert on this.

However, I may be wrong because I just took a quick look at the bug
report, but I do not see any modifications to the patches tagged as
'needs-work'. Adding classes' .hg and .ccg files without adding them
to is safe, as the build will not break, but it is kind of
pointless. So I think yes, maybe creating self-contained patches would
ease the process of getting them into cluttermm.

Best regards,

On Mon, Mar 3, 2014 at 8:29 AM, Ian Martin <martin_id vodafone co nz> wrote:
I have a few questions regarding how to get the patchset accepted to update

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/ file, the src/clutter/ 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

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
                                                         const GValue

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

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

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?


gtkmm-list mailing list
gtkmm-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]