hi Jonathon;
On Mon, 2007-10-29 at 08:25 -0500, Jonathon Jongsma wrote:
> So I guess my question is, which version most closely satisfies the
> intent of the API? Is modifying a color directly (e.g.
> clutter_color_darken(&foo, &foo)) an expected and common use case? (i
> looked at the implementation and it seems that src == dest should be
> safe at least).
while modifying a color in place using
clutter_color_darken (&foo, &foo);
is allowed, I don't consider it very common; for instance, I have code
that lightens a rectangle on enter-event, which looks like:
if (event->type == CLUTTER_ENTER)
{
ClutterColor light_color = { 0xff, };
clutter_color_lighten (&default_color, &light_color);
clutter_rectangle_set_color (rect, &light_color);
}
else if (event->type == CLUTTER_LEAVE)
clutter_rectangle_set_color (rect, &default_color);
and I keep default_color around as a static const variable.
> Any other bindings authors care to share why they
> made the decisions they did?
with my Perl/Python bindings author hat on: the API is a bit awkward any
way you put it - the wonders of C arguments passing badly translate to
anything that's not C. :-)
Personally, I went for the [B] approach:
my $foo = Clutter::Color->new();
my $dark_foo = $foo->darken();
for both Perl and Python, because it mapped the GdkColor bindings as
well (least resistance path for migrating code :-)). lighten(), darken()
and shade() take a Clutter::Color object and return a newly created
Color, implicitly copying the original for you.
ciao,
Emmanuele.
--
Emmanuele Bassi, OpenedHand Ltd.
Unit R, Homesdale Business Centre
216-218 Homesdale Rd., Bromley - BR12QZ
http://www.o-hand.com
--
To unsubscribe send a mail to [EMAIL PROTECTED]
