Hi Felipe,
Filipe Nepomuceno wrote:
very expensive solution though (if it works) because of the trig
function calls
You can always just precompute the trig values into an array or use a
polynomial approximation. You just need to clamp the angle to the right
range in an accessor function in
Emmanuele Bassi wrote:
It would be nice to have a way to convert coordinates between arbitrary
actors though.
clutter_actor_apply_relative_transform_to_point() is the function you
want.
remember, though, that transformations are performed by the CPU and
might be costly or even fail.
Hi,
when a group is made reactive and receives a mouse event the event
coordinates are relative to the stage.
Because the group coordinates rotate and transform with the group (so
that x in a rotated group is actually a position along a possibly
diagonal line) one cannot easily make natural
Rajith Kalluraya wrote:
Hi,
You can do a clutter_grab_pointer on the scrollbar widget in its button
press handler. Motion events and the release events will be received by
the scrollbar widget no matter where the mouse is.
Make sure you call clutter_ungrab_pointer in the release handler.
Murray Cumming wrote:
On Sun, 2009-06-07 at 12:05 +0200, Bartosz Kostrzewa wrote:
Attached is a simple test case which explains what the problem is. The
ending of Clutter::main() does not remove actors from the stage.
stage-remove_actor(object) has to be called explicitly for the
reference
Emmanuele Bassi wrote:
On Sun, 2009-06-07 at 12:05 +0200, Bartosz Kostrzewa wrote:
Attached is a simple test case which explains what the
problem is. The
ending of Clutter::main() does not remove actors from the stage.
this is how Clutter works; the scenegraph is *not* destroyed
Hi everyone,
I have a simple UI which relies in its logic on calling get_scale to
control an animation but I've noticed that while an actor is being
animated via calling set_scale in a *new_frame signal handler, get_scale
keeps returning 1.0 until about half a second after the timeline
animating
Bartosz Kostrzewa wrote:
animated via calling set_scale in a *new_frame signal handler, get_scale
keeps returning 1.0 until about half a second after the timeline
animating the set_scale operation has finished.
apologies for replying to my own post but it's not even as regular
Bartosz Kostrzewa wrote:
Is this expected behaviour? Is there something I can do to guarantee
that the value of set_scale is propagated so that get_scale returns the
correct one?
Ok, disregard this, the problem was that clicking triggered the
animation of an underlying texture which
