On Wed, 2008-03-12 at 19:39 +0100, API wrote: > But on clutter you have the next: > clutter_actor_get_geometry(actor, &geometry) > > But this returns the position relative to the stage (AFAIK, please correct me > if I'm wrong), so it starts to count from (0,0), not from the top level window > position.
get_geometry(), like get_position(), get_x(), get_y() and get_coords() will return the (untransformed) coordinates of an actor relative to the parent. you can traverse the entire scenegraph using clutter_actor_get_parent() and get the coordinates of the (untransformed) bounding box of any actor on the stage - relative to the stage. if you want to know the position of the stage you'll have to use backend-specific API, as the stage depends on the windowing environment used. on X11 you'll have to get the Window of the stage and query its position. > This problem can be workarounded if you are using the clutter stage inside a > GtkClutterEmbed, so you can use clutter_actor_get_geometry to get the relative > position, and use the gdk_window_get_origin, as I said previously, with the > GtkClutterEmbed to get the absolute position of the toplevel. I was able to > do > that, and seems to work. yes: GtkClutterEmbed offloads the entire windowing handling to GTK+ - and that has cross-platform API for handling the various windowing systems. we'd rather not replicate the entire GdkWindow API inside Clutter - especially since it's possible to efficiently embed it inside a GtkWindow. a "pure Clutter" application, as you inferred, will have to know on which backend it's running, and use the appropriate API for that. 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]
