Re: [clutter] ClutterColor API bindings questions
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]
Re: [clutter] ClutterColor API bindings questions
Jonathon Jongsma wrote: Hello all. I've been thinking about playing with clutter lately, so I started working on some C++ bindings. I've got a couple of questions about the ClutterColor API. There are several functions which take a src and a dest color argument. For this email, I'll just focus on clutter_color_darken(), but the issues apply to several other functions as well. If I was to wrap this API directly into an object-oriented style, I would end up with something like: void Color::darken(Color dest) const; [A] or alternately Color Color::darken() const; [B] The problem with wrapping these functions in this way is that it seems to lose some of the flexibility of the C version. For example, with the C version, you can darken a color directly, or save a darkened version of the src color in another Color object. For example: // foo and bar are ClutterColor objects // darken foo directly: clutter_color_darken(foo, foo); // make bar a darkened version of foo clutter_color_darken(foo, bar); Now, with version A above, we could do both of these cases as well, but it seems quite awkward to do something like this in C++: foo.darken(foo); Version B above is a more natural syntax, but makes it impossible to modify the color itself -- the darkened color is always a copy (which could have some performance implications as well). This also makes for slightly awkward code in the case where you just want to work with the darkened color and don't want to keep around the original, e.g.: Color foo; Color bar = foo.darken(); // don't care about foo anymore So I had an idea to just modify the src object directly and omit the dest parameter, e.g.: void Color::darken(); [C] This means that if you wanted to create a darkened copy of the original color, you would have to make the copy yourself, e.g.: Color foo; Color dark_foo = foo; dark_foo.darken(); There are drawbacks to all of these options, but I'm leaning towards wrapping it using version [C]. I looked at what other bindings did, and it seems that the vala and C# bindings both chose version [A], the python and ruby bindings both chose [B], and I couldn't figure out what the perl bindings did :) 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). Any other bindings authors care to share why they made the decisions they did? The beauty of C++ is that you can have all three functions, although I personally would just do B and C. Of course, whether there is anything other than overhead to be gained by C++ bindings for a C library is open to question. Tomas -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] ClutterColor API bindings questions
On Mon, 2007-10-29 at 13:56 +, Neil Roberts wrote: On an sort of related note, I think there is a slight issue with clutter_color_darken that I worked around in the Ruby bindings which is that the alpha value of the destination is not copied over from the source and is left uninitialised. So you have to make sure you initialise the destination color if src != dest. it was a bug in clutter_color_shade(), the function that lighten() and darken() just wrap; I fixed it in trunk, but probably forgot to backport the patch to the stable branch. thanks for reminding me. :-) 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]
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] ClutterColor API bindings questions
(no need to Cc: me in :-)) On Mon, 2007-10-29 at 15:44 +0100, Murray Cumming wrote: 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. as I wrote, clutter_color_darken() is just a convenience wrapper around clutter_color_shade(), if I want to darken a given color without really caring about the amount of darkening. it's useful for simple roll-overs or for highlighting actors in a consistent fashion. 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]
