GNOME Bugzilla – Bug 553157
Timeline using wrong property name + completely wrong/incomplete wrapper over TimeoutPool?
Last modified: 2008-09-25 18:48:51 UTC
cluttermm and clutter from svn trunk, as of today (hopefully 0.8) a) Clutter::Timeline seems to use the property "msecs" while the property should be 'duration' !? b) Clutter::TimeoutPool unusable. Linker can't find Clutter::TimeoutPool(int msec) After 2 minutes of research, I think the wrapping is not done at all. My observations: 1) the 2 functions defined as wrappers (add/remove) seems to treat the TimeoutPool as a GObject. But looking at the implementation from clutter, it doesn't look like so. 2) headers from cluttermm *do* define as explicit that constructor, but implementation is missing. Hope that helps.
Thanks, both are fixed with these commits: 2008-09-23 Murray Cumming <murrayc@murrayc.com> * clutter/src/timeout-pool.ccg: * clutter/src/timeout-pool.hg: Implement the constructor. Bug #553157 (Cristi Posoiu) Added a destructor, though it is not clear how we should free the C struct. See http://bugzilla.o-hand.com/show_bug.cgi?id=1154 2008-09-23 Murray Cumming <murrayc@murrayc.com> * clutter/src/timeline.hg: Constructor: Rename the msecs parameter to duration so that the implementation uses the correct property name. Bug #553157 (Cristi Posoiu) In future, please don't put two bug reports in one bugzilla bug. It would be great if you could provide an example of the use of TimeoutPool.
a) 2 bug reports in one: yes, you're right. I guess I was lazy because even myself wouldn't want such bug reports :-) Sorry. b) usage - I just wanted a "timeout" notification, for some GUI stuff. Thinking of the fact that if using too many timeouts for simple GUI, from glib, might not be good, I saw the clutter docs suggesting this might be the right thing to use. I wasn't at that moment also sure if clutter uses or not Glib and its event system for example. In the end, even though it worked w/ my simple wrapper, I got to a better solution for my particular case, which didn't involve any "timeout" at all. c) thanks for the quick fixes d) Nice catch w/ the destructor - haven't seen it!
Based on the comments in the C bug, I will remove Glib::TimoutPool. "I saw the clutter docs suggesting this might be the right thing to use" Do you have a URL for that?
The info about use of timeoutpool is inside their document at http://www.clutter-project.org/docs/clutter/0.8/clutter-Utilities.html I think they might have just updated the doc to say it is "not for app. dev" !? :) The interesting parts that made me thinking of using this and makes me think it will be good to have it in: a) A timeout pool should be used when multiple timeout functions, running at the same priority, are needed and the g_timeout_add() API might lead to starvation of the time slice of the main loop. (I thought scalability issues if I would end up using too many "timeouts"/timelines for GUI) b) Since version 0.8 this will try to compensate for delays (I thought this could be interesting for some usage - not necessarily GUI) Haven't looked if Glib offers b) though neither have I done any scalability measurements. I read also the C bug report but I couldn't see a good reason for not exporting it, taking into account a) and b). And looking at post (last one at this moment) "Emmanuele Bassi 2008-09-23 14:21:39" and the fact that the wrapper is simple to do, my suggestion is to keep it.