hi; for future reference, just open a bug in bugzilla: it's easier to attach patches and track the discussion for us. :-)
On Thu, 2008-01-31 at 20:28 +0100, benoar wrote: > A timeline has a current_frame_num variable which tells the current > frame number. To me, it should be included in the interval > [0,n_frames-1], do you agree ? for "historical reasons", we defined the interval of a timeline to be [0, n_frames]. since both explicit animations and implicit animations depend on this interval, I think it's a bit too late to change it and expect everything to work. all the alpha functions, for instance, would have to be changed to take into account the new interval. > Because a lot of tests in clutter-timeline.c let this variable go to > n_frames. Most of the test are on "current_frame_num > n_frames", > which is wrong if you don't want current_frame_num to be equal to > n_frames. !(current_frame_num > n_frames) will evaluate as FALSE if the user or the timeline itself try to set the frame number to something that's bigger than the number of frames - which is pretty consistent with the interval as it has been defined (that is, [0, n_frames]). > It is strange that this kind of error has not be spotted earlier, so > maybe these particular tests were intentional. But the convention in C > is for the "indexes" to be from 0 to max_count-1, isn't it ? a timeline is not an array index, though. :-) every check you mentioned is consistent to the given range. > PS: I also spotted another bug, a double increment, line 782: it should be > removed: > priv->current_frame_num += n_frames; yes, that's truly a typo. well spotted! I've just fixed it in SVN. 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]
