mirror of
https://github.com/brl/mutter.git
synced 2024-09-21 06:56:12 -04:00
1413 lines
49 KiB
XML
1413 lines
49 KiB
XML
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
|
<chapter id="events" xmlns:xi="http://www.w3.org/2003/XInclude">
|
|
<title>Events</title>
|
|
|
|
<epigraph>
|
|
<attribution>The Tenth Doctor (David Tennant)</attribution>
|
|
<para>Crossing into established events is strictly forbidden. Except for
|
|
cheap tricks.</para>
|
|
</epigraph>
|
|
|
|
<section id="events-introduction">
|
|
<title>Introduction</title>
|
|
<para>Once you have set up a scene on the stage, in order to respond
|
|
to user interaction you will have to handle events coming from the
|
|
underlying platform.</para>
|
|
|
|
<para>Events are relayed to actors by Clutter in form of
|
|
<emphasis>signals</emphasis>; signals are a facility provided by the
|
|
GObject framework to call functions depending on a unique name. A signal
|
|
can be thought as a message that an object instance broadcasts to various
|
|
listener functions.</para>
|
|
|
|
<para>There are various events that Clutter will handle: mostly, they
|
|
deal with input devices, like a mouse pointer or a keyboard; but they can
|
|
also come from the windowing system, like the
|
|
<emphasis>delete-event</emphasis> signal that is emitted when the user
|
|
closes the window of the stage.</para>
|
|
|
|
<para>Each event has a particular <emphasis>source</emphasis>, that is
|
|
the actor that received the event. The event handling sequence is divided
|
|
in two phases:</para>
|
|
|
|
<orderedlist>
|
|
<listitem><para>the <emphasis>capture</emphasis> phase, which consists
|
|
in an emission of the <emphasis>captured-event</emphasis> signal
|
|
starting from the stage to, following the parent-child relationship,
|
|
the source of the event;</para></listitem>
|
|
<listitem><para>the <emphasis>bubble</emphasis> phase, which consists
|
|
in an emission of the <emphasis>event</emphasis> signal starting from
|
|
the source of the event to, following the parent-child
|
|
relationship, the stage.</para></listitem>
|
|
</orderedlist>
|
|
|
|
<para>At any point during the event emission sequence a handler of either
|
|
the captured-event or the event signals can stop it, by returning a value
|
|
of TRUE, which means that the event has been handled. If an event hasn't
|
|
been handled, FALSE should be returned instead.</para>
|
|
</section>
|
|
|
|
<section id="events-handling-key-events">
|
|
<title>Handling key events</title>
|
|
|
|
<section>
|
|
<title>Problem</title>
|
|
<para>You want to respond to key presses on an actor.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Solutions</title>
|
|
|
|
<para>There are two possible solutions:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>Solution 1:</emphasis> Connect a callback to the
|
|
actor; inside the callback, manually analyse which key and
|
|
modifier(s) were pressed and react accordingly.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis>Solution 2:</emphasis> Use an actor's
|
|
<type>ClutterBindingPool</type> to declaratively assign
|
|
actions to specific key and modifier combinations.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Each solution is covered below.</para>
|
|
|
|
<section>
|
|
<title>Solution 1</title>
|
|
|
|
<para>Connect the <emphasis>key-press-event</emphasis>
|
|
signal for an actor to a callback; then examine the event
|
|
in the callback to determine which key and modifiers were
|
|
pressed.</para>
|
|
|
|
<para>First, connect an actor's
|
|
<emphasis>key-press-event</emphasis> signal to a callback:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
g_signal_connect (actor, "key-press-event", G_CALLBACK (_key_press_cb), NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Then, in the callback, check which key was pressed and which
|
|
modifiers were down at the same time. For example, this callback
|
|
checks for a press on the up arrow key and whether
|
|
the <keycap>Shift</keycap> and/or <keycap>Ctrl</keycap>
|
|
key were down:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
static gboolean
|
|
_key_press_cb (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
guint keyval = clutter_event_get_key_symbol (event);
|
|
|
|
ClutterModifierType state = clutter_event_get_state (event);
|
|
gboolean shift_pressed = (state & CLUTTER_SHIFT_MASK ? TRUE : FALSE);
|
|
gboolean ctrl_pressed = (state & CLUTTER_CONTROL_MASK ? TRUE : FALSE);
|
|
|
|
if (CLUTTER_KEY_Up == keyval)
|
|
{
|
|
if (shift_pressed & ctrl_pressed)
|
|
g_debug ("Up and shift and control pressed");
|
|
else if (shift_pressed)
|
|
g_debug ("Up and shift pressed");
|
|
else
|
|
g_debug ("Up pressed");
|
|
|
|
/* The event was handled, and the emission should stop */
|
|
return TRUE;
|
|
}
|
|
|
|
/* The event was not handled, and the emission should continue */
|
|
return FALSE;
|
|
}
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<note>
|
|
<para>Clutter provides a range of key value definitions
|
|
(like <constant>CLUTTER_KEY_Up</constant>, used above). These are
|
|
generated from the list in the
|
|
<ulink url="http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h">X.Org source code</ulink>
|
|
(replace "XK" with "CLUTTER_KEY" in the definitions there to get the
|
|
Clutter equivalents; alternatively, look at the
|
|
<filename>clutter-keysyms.h</filename> header file for the
|
|
list).</para>
|
|
|
|
<para><constant>CLUTTER_SHIFT_MASK</constant>,
|
|
<constant>CLUTTER_CONTROL_MASK</constant> and other modifiers are
|
|
defined in the <type>ClutterModifierType</type> enum.</para>
|
|
</note>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Solution 2</title>
|
|
|
|
<para>Assign actions to an actor's <type>ClutterBindingPool</type>.
|
|
A binding pool stores mappings from a key press (either a single key
|
|
or a key plus modifiers) to actions; an action is simply a callback
|
|
function with a specific signature.</para>
|
|
|
|
<para>While this approach is trickier to implement, it is more
|
|
flexible and removes the drudgery of writing branching code to
|
|
handle different key presses. See the
|
|
<link linkend="events-handling-key-events-discussion">Discussion</link>
|
|
section for more details.</para>
|
|
|
|
<para>To use this approach with an actor which will receive key press
|
|
events, first get that actor's binding pool. In the example below,
|
|
we're using the binding pool for the default
|
|
<type>ClutterStage</type>:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
ClutterBindingPool *binding_pool;
|
|
GObjectClass *stage_class;
|
|
|
|
stage_class = CLUTTER_STAGE_GET_CLASS (stage);
|
|
binding_pool = clutter_binding_pool_get_for_class (stage_class);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Next, install actions into the binding pool. For example, to
|
|
install an action bound to the up arrow key, which calls the
|
|
<function>_move_up()</function> function when that key is pressed,
|
|
you would do:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
clutter_binding_pool_install_action (binding_pool,
|
|
"move-up", /* identifier */
|
|
CLUTTER_KEY_Up, /* up arrow pressed */
|
|
0, /* no modifiers pressed */
|
|
G_CALLBACK (_move_up),
|
|
NULL, /* no user data passed */
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Another example, binding up arrow +
|
|
<keycap>Shift</keycap> + <keycap>Ctrl</keycap> to an action
|
|
which calls <function>_move_up_shift_control()</function> when
|
|
activated:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
clutter_binding_pool_install_action (binding_pool,
|
|
"move-up-shift-control",
|
|
CLUTTER_KEY_Up,
|
|
CLUTTER_SHIFT_MASK + CLUTTER_CONTROL_MASK,
|
|
G_CALLBACK (_move_up_shift_control),
|
|
NULL,
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The function called when an action is activated looks
|
|
like this (for <function>_move_up()</function>):</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
static void
|
|
_move_up (GObject *instance,
|
|
const gchar *action_name,
|
|
guint key_val,
|
|
ClutterModifierType modifiers,
|
|
gpointer user_data)
|
|
{
|
|
g_debug ("Up pressed");
|
|
}
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Then bind the <emphasis>key-press-event</emphasis> signal
|
|
for the actor (in our case, the stage) to a callback:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
g_signal_connect (stage,
|
|
"key-press-event",
|
|
G_CALLBACK (_key_press_cb),
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Finally, inside the callback, pass control to the actor's
|
|
binding pool rather than dissecting the key press event
|
|
yourself:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
static gboolean
|
|
_key_press_cb (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
ClutterBindingPool *pool;
|
|
|
|
pool = clutter_binding_pool_find (G_OBJECT_TYPE_NAME (actor));
|
|
|
|
return clutter_binding_pool_activate (pool,
|
|
clutter_event_get_key_symbol (event),
|
|
clutter_event_get_state (event),
|
|
G_OBJECT (actor));
|
|
}
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Now, when a key + modifiers that have been bound to an action
|
|
are pressed on the actor, the appropriate action is activated.</para>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section id="events-handling-key-events-discussion">
|
|
<title>Discussion</title>
|
|
|
|
<section>
|
|
<title>Pros and cons of Solution 1 and Solution 2</title>
|
|
|
|
<para>Solution 1 is the simplest (in terms of the amount of code you
|
|
have to write for simple cases), but could quickly turn into a mess if
|
|
you need many conditions or want to capture many key combinations.
|
|
Also, if multiple actors need to respond to key press events, you'll
|
|
need similar event dissection code in each callback.</para>
|
|
|
|
<para>Solution 2 is more complicated to implement, but scales better
|
|
if you have many different key combinations on multiple actors.
|
|
The binding pool protects you from the minutiae of detecting which
|
|
keys were pressed, leaving you to concentrate on the
|
|
triggered actions instead. This could simplify your control
|
|
logic.</para>
|
|
|
|
<para>In addition, Solution 2 lets you write a single callback to
|
|
handle all key press events for all actors. This callback could then
|
|
use <function>clutter_binding_pool_find()</function>
|
|
(as in the example code) to determine which binding pool to
|
|
activate (depending on which actor received the key press
|
|
event).</para>
|
|
|
|
<para>Finally, a binding pool allows you to block and unblock actions.
|
|
This means you can make the response to a key press event conditional
|
|
on application state. For example, let's say you wanted the up arrow
|
|
key to move an actor, but only when the actor is at the bottom
|
|
of the stage. To implement this, you could disable the up arrow key
|
|
action in the binding pool initially; then, once the actor reaches the
|
|
bottom of the stage, enable the up arrow key action again. While this
|
|
is possible with Solution 1, you would have to implement more of the
|
|
state management code yourself.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Other useful things to know about key press events</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A <type>ClutterKeyEvent</type> contains only a
|
|
<emphasis>single</emphasis> key value, plus possibly one
|
|
or more modifier keys (like <keycap>Shift</keycap>,
|
|
<keycap>Ctrl</keycap>, <keycap>Alt</keycap> etc.).
|
|
There are no functions in the Clutter API which return
|
|
events for tracking near-simultaneous presses on multiple
|
|
keys.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>By default, the stage receives all key events.
|
|
To make another actor receive key events, use
|
|
<function>clutter_stage_set_key_focus()</function>:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
/*
|
|
* stage is a ClutterStage instance;
|
|
* actor is the ClutterActor instance which should receive key events
|
|
*/
|
|
clutter_stage_set_key_focus (stage, actor);
|
|
</programlisting>
|
|
</informalexample>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section id="events-mouse-scroll">
|
|
<title>Detecting mouse scrolling on an actor</title>
|
|
|
|
<section>
|
|
<title>Problem</title>
|
|
|
|
<para>You want to detect when the mouse is scrolled on an
|
|
actor (e.g. the pointer is over an actor when a mouse
|
|
wheel is scrolled).</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Solution</title>
|
|
|
|
<para>Connect a callback handler to the <code>scroll-event</code>
|
|
signal of an actor.</para>
|
|
|
|
<para>First, ensure that the actor is reactive (i.e. will
|
|
respond to events):</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
clutter_actor_set_reactive (actor, TRUE);
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Next, create a callback handler to examine the scroll
|
|
event and respond to it:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
static gboolean
|
|
_scroll_event_cb (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
/* determine the direction the mouse was scrolled */
|
|
ClutterScrollDirection direction;
|
|
direction = clutter_event_get_scroll_direction (event);
|
|
|
|
/* replace these stubs with real code to move the actor etc. */
|
|
switch (direction)
|
|
{
|
|
case CLUTTER_SCROLL_UP:
|
|
g_debug ("Scrolled up");
|
|
break;
|
|
case CLUTTER_SCROLL_DOWN:
|
|
g_debug ("Scrolled down");
|
|
break;
|
|
case CLUTTER_SCROLL_RIGHT:
|
|
g_debug ("Scrolled right");
|
|
break;
|
|
case CLUTTER_SCROLL_LEFT:
|
|
g_debug ("Scrolled left");
|
|
break;
|
|
}
|
|
|
|
return TRUE; /* event has been handled */
|
|
}
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Finally, connect the callback handler to the
|
|
<code>scroll-event</code> signal of the actor:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
g_signal_connect (actor,
|
|
"scroll-event",
|
|
G_CALLBACK (_scroll_event_cb),
|
|
NULL);
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Discussion</title>
|
|
|
|
<para>A standard mouse wheel will only return up and
|
|
down movements; but in cases where the mouse has left and
|
|
right scrolling (e.g. a trackball mouse or trackpad), left and
|
|
right scroll events may also be emitted.</para>
|
|
|
|
<section>
|
|
<title>Creating a scrolling viewport for an actor</title>
|
|
|
|
<para>While the simple outline above explains the basics
|
|
of how to connect to scroll events, it doesn't do much to
|
|
help with <emphasis>really</emphasis> implementing scrolling
|
|
over an actor. That's what we'll do in this section.</para>
|
|
|
|
<note>
|
|
<para>The full code for the example we'll walk through here is
|
|
available in <link linkend="events-mouse-scroll-example">this later
|
|
section</link>.</para>
|
|
</note>
|
|
|
|
<para>Scrolling over an actor actually requires coordination
|
|
between two components:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<formalpara>
|
|
<title>Scrollable actor</title>
|
|
<para>An actor which is too large to fit on the stage
|
|
or inside the area of the UI assigned to it (otherwise
|
|
there's no need to scroll over it...).</para>
|
|
</formalpara>
|
|
</listitem>
|
|
<listitem>
|
|
<formalpara>
|
|
<title>Viewport</title>
|
|
<para>This displays a cropped view of part of the scrollable
|
|
actor, revealing different parts of it as scroll events
|
|
occur.</para>
|
|
</formalpara>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Here are the steps required to set up the two actors:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Create the scrollable actor; it should be larger
|
|
than the viewport. This example uses a <type>ClutterTexture</type>,
|
|
but any <type>ClutterActor</type> will work:</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
/* get image file path, set up stage etc. */
|
|
|
|
ClutterActor *texture;
|
|
texture = clutter_texture_new ();
|
|
clutter_texture_set_keep_aspect_ratio (CLUTTER_TEXTURE (texture),
|
|
TRUE);
|
|
|
|
/*
|
|
* set the texture's height so it's as tall as the stage
|
|
* (STAGE_HEIGHT is define'd at the top of the file)
|
|
*/
|
|
clutter_actor_set_request_mode (texture, CLUTTER_REQUEST_WIDTH_FOR_HEIGHT);
|
|
clutter_actor_set_height (texture, STAGE_HEIGHT);
|
|
|
|
/*
|
|
* load the image file;
|
|
* see <link linkend="textures-aspect-ratio">this recipe</link> for more about loading images into textures
|
|
*/
|
|
clutter_texture_set_from_file (CLUTTER_TEXTURE (texture),
|
|
image_file_path,
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>Create the viewport. The simplest way to do
|
|
this is with a <type>ClutterGroup</type>:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
ClutterActor *viewport;
|
|
viewport = clutter_group_new ();
|
|
|
|
/* viewport is _shorter_ than the stage (and the texture) */
|
|
clutter_actor_set_size (viewport, STAGE_WIDTH, STAGE_HEIGHT * 0.5);
|
|
|
|
/* align the viewport to the center of the stage's y axis */
|
|
clutter_actor_add_constraint (viewport,
|
|
clutter_align_constraint_new (stage, CLUTTER_BIND_Y, 0.5));
|
|
|
|
/* viewport needs to respond to scroll events */
|
|
clutter_actor_set_reactive (viewport, TRUE);
|
|
|
|
/* clip all actors inside the viewport to that group's allocation */
|
|
clutter_actor_set_clip_to_allocation (viewport, TRUE);
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The key here is calling
|
|
<code>clutter_actor_set_clip_to_allocation (viewport, TRUE)</code>.
|
|
This configures the <varname>viewport</varname> group so
|
|
that any of its children are clipped: i.e. only parts of
|
|
its children which fit inside its allocation are visible. This
|
|
in turn requires setting an explicit size on the group,
|
|
rather than allowing it to size itself to fit its
|
|
children (the latter is the default).</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Put the scrollable actor into the viewport; and
|
|
the viewport into its container (in this case,
|
|
the default stage):</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
clutter_container_add_actor (CLUTTER_CONTAINER (viewport), texture);
|
|
|
|
clutter_container_add_actor (CLUTTER_CONTAINER (stage), viewport);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Create a callback handler for <code>scroll-event</code>
|
|
signals emitted by the viewport:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
<![CDATA[
|
|
static gboolean
|
|
_scroll_event_cb (ClutterActor *viewport,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
ClutterActor *scrollable = CLUTTER_ACTOR (user_data);
|
|
|
|
gfloat viewport_height = clutter_actor_get_height (viewport);
|
|
gfloat scrollable_height = clutter_actor_get_height (scrollable);
|
|
|
|
/* no need to scroll if the scrollable is shorter than the viewport */
|
|
if (scrollable_height < viewport_height)
|
|
return TRUE;
|
|
|
|
gfloat y = clutter_actor_get_y (scrollable);
|
|
|
|
ClutterScrollDirection direction;
|
|
direction = clutter_event_get_scroll_direction (event);
|
|
|
|
switch (direction)
|
|
{
|
|
case CLUTTER_SCROLL_UP:
|
|
y -= SCROLL_AMOUNT;
|
|
break;
|
|
case CLUTTER_SCROLL_DOWN:
|
|
y += SCROLL_AMOUNT;
|
|
break;
|
|
|
|
/* we're only interested in up and down */
|
|
case CLUTTER_SCROLL_LEFT:
|
|
case CLUTTER_SCROLL_RIGHT:
|
|
break;
|
|
}
|
|
|
|
/*
|
|
* the CLAMP macro returns a value for the first argument
|
|
* that falls within the range specified by the second and
|
|
* third arguments
|
|
*
|
|
* we allow the scrollable's y position to be decremented to the point
|
|
* where its base is aligned with the base of the viewport
|
|
*/
|
|
y = CLAMP (y,
|
|
viewport_height - scrollable_height,
|
|
0.0);
|
|
|
|
/* animate the change to the scrollable's y coordinate */
|
|
clutter_actor_animate (scrollable,
|
|
CLUTTER_EASE_OUT_CUBIC,
|
|
300,
|
|
"y", y,
|
|
NULL);
|
|
|
|
return TRUE;
|
|
}
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The approach taken here is to move the scrollable
|
|
actor up, relative to the viewport. Initially, the
|
|
scrollable will have a <code>y</code> coordinate value
|
|
of <code>0.0</code> (aligned to the top of the viewport).
|
|
Scrolling up decrements the
|
|
<code>y</code> coordinate (down to a minumum of
|
|
<code>viewport_height - scrollable_height</code>). This moves
|
|
the top of the scrollable actor "outside" the clip area of the
|
|
viewport; simultaneously, more of the bottom part of the
|
|
scrollable moves into the clip area, becoming visible.</para>
|
|
|
|
<para>Scrolling down increments the <code>y</code> coordinate
|
|
(but only up to a maximum value of <code>0.0</code>).</para>
|
|
|
|
<para>To see how this works in practice, look at
|
|
<link linkend="events-mouse-scroll-example">the code
|
|
sample</link>. There, the height of the scrollable actor is
|
|
set to <code>300</code> and the height of the viewport to
|
|
<code>150</code>. This means that the <code>y</code>
|
|
coordinate value for the scrollable actor will vary between
|
|
<code>-150.0</code>: <code>150</code> (the viewport's height)
|
|
<code>- 300</code> (the scrollable actor's height), making
|
|
its base visible and clipping its top; and
|
|
<code>0.0</code>, where its top is visible and its base
|
|
clipped.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Connect the callback handler to the signal; note
|
|
that we pass the scrollable actor (the texture) to the callback,
|
|
as we're moving the texture relative to the viewport to
|
|
create the scrolling effect:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
g_signal_connect (viewport,
|
|
"scroll-event",
|
|
G_CALLBACK (_scroll_event_cb),
|
|
texture);
|
|
</programlisting>
|
|
</informalexample>
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
<para>Here's a video of the result:</para>
|
|
|
|
<inlinemediaobject>
|
|
<videoobject>
|
|
<videodata fileref="videos/events-mouse-scroll.ogv"/>
|
|
</videoobject>
|
|
<alt>
|
|
<para>Video showing a scrollable actor</para>
|
|
</alt>
|
|
</inlinemediaobject>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Full example</title>
|
|
|
|
<example id="events-mouse-scroll-example">
|
|
<title>Mouse scrolling over a <type>ClutterActor</type></title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-mouse-scroll.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section id="events-pointer-motion">
|
|
<title>Detecting pointer movements on an actor</title>
|
|
|
|
<section id="events-pointer-motion-problem">
|
|
<title>Problem</title>
|
|
|
|
<para>You want to be able to tell when the pointer (e.g. associated
|
|
with a mouse or touches on a screen) enters, leaves, or moves over
|
|
an actor.</para>
|
|
|
|
<para>Example use cases include:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Adding a tooltip or hover effect to an actor when
|
|
a pointer moves onto it.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Tracing the path of the pointer over an actor (e.g.
|
|
in a drawing application).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section id="events-pointer-motion-solution">
|
|
<title>Solution</title>
|
|
|
|
<para>Connect to the pointer motion signals emitted by the actor.</para>
|
|
|
|
<section>
|
|
<title>Responding to crossing events</title>
|
|
|
|
<para>To detect the pointer crossing the boundary of an actor
|
|
(entering or leaving), connect to the <code>enter-event</code>
|
|
and/or <code>leave-event</code> signals. For example:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
ClutterActor *actor = clutter_texture_new ();
|
|
|
|
/* ...set size, color, image etc., depending on the actor... */
|
|
|
|
/* make the actor reactive: see <link linkend="events-pointer-motion-discussion">Discussion</link> for more details */
|
|
clutter_actor_set_reactive (actor, TRUE);
|
|
|
|
/* connect to the signals */
|
|
g_signal_connect (actor,
|
|
"enter-event",
|
|
G_CALLBACK (_pointer_enter_cb),
|
|
NULL);
|
|
|
|
g_signal_connect (actor,
|
|
"leave-event",
|
|
G_CALLBACK (_pointer_leave_cb),
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The signature for callbacks connected to each of these
|
|
signals is:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
gboolean
|
|
_on_crossing (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>In the callback, you can examine the event to get the
|
|
coordinates where the pointer entered or left the actor. For
|
|
example, <function>_pointer_enter_cb()</function> could
|
|
follow this template:</para>
|
|
|
|
<informalexample id="events-pointer-motion-callback-example">
|
|
<programlisting>
|
|
<![CDATA[
|
|
/* the event passed to the callback is of type ClutterCrossingEvent */
|
|
static gboolean
|
|
_pointer_enter_cb (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
/* get the coordinates where the pointer crossed into the actor */
|
|
gfloat stage_x, stage_y;
|
|
clutter_event_get_coords (event, &stage_x, &stage_y);
|
|
|
|
/*
|
|
* as the coordinates are relative to the stage, rather than
|
|
* the actor which emitted the signal, it can be useful to
|
|
* transform them to actor-relative coordinates
|
|
*/
|
|
gfloat actor_x, actor_y;
|
|
clutter_actor_transform_stage_point (actor,
|
|
stage_x, stage_y,
|
|
&actor_x, &actor_y);
|
|
|
|
g_debug ("pointer at stage x %.0f, y %.0f; actor x %.0f, y %.0f",
|
|
stage_x, stage_y,
|
|
actor_x, actor_y);
|
|
|
|
return TRUE;
|
|
}
|
|
]]>
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>See <link linkend="events-pointer-motion-example-1">the
|
|
code example in the appendix</link> for an example of how
|
|
you can implement a hover effect on a "button" (rectangle
|
|
with text overlay) using this approach.</para>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Responding to motion events</title>
|
|
|
|
<para>Motion events occur when a pointer moves over an actor;
|
|
the actor emits a <code>motion-event</code> signal when this
|
|
happens. To respond to motion events, connect to this signal:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
/* set up the actor, make reactive etc., as above */
|
|
|
|
/* connect to motion-event signal */
|
|
g_signal_connect (actor,
|
|
"motion-event",
|
|
G_CALLBACK (_pointer_motion_cb),
|
|
transitions);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The signature of the callback is the same as for
|
|
the <code>enter-event/leave-event</code> signals, so you can use
|
|
<link linkend="events-pointer-motion-callback-example">code
|
|
similar to the above</link> to handle it. However, the
|
|
type of the event is a <type>ClutterMotionEvent</type>
|
|
(rather than a <type>ClutterCrossingEvent</type>).</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section id="events-pointer-motion-discussion">
|
|
<title>Discussion</title>
|
|
|
|
<para>A few more useful things to know about pointer motion
|
|
events:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>Each crossing event is accompanied by a motion event at
|
|
the same coordinates.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Before an actor will emit signals for pointer events,
|
|
it needs to be made reactive with:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
clutter_actor_set_reactive (actor, TRUE);
|
|
</programlisting>
|
|
</informalexample>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A pointer event structure includes other data. Some
|
|
examples:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
/* keys and mouse buttons pressed down when the pointer moved */
|
|
ClutterModifierType modifiers = clutter_event_get_state (event);
|
|
|
|
/* time (since the epoch) when the event occurred */
|
|
guint32 event_time = clutter_event_get_time (event);
|
|
|
|
/* actor where the event originated */
|
|
ClutterActor *actor = clutter_event_get_actor (event);
|
|
|
|
/* stage where the event originated */
|
|
ClutterStage *stage = clutter_event_get_stage (event);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>There's no need to cast the event to use these
|
|
functions: they will work on any <type>ClutterEvent</type>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The coordinates of an event (as returned by
|
|
<function>clutter_event_get_coords()</function>) are relative
|
|
to the stage where they originated, rather than the actor. Unless
|
|
the actor is the same size as the stage, you'll typically want
|
|
the actor-relative coordinates instead. To get those, use
|
|
<function>clutter_actor_transform_stage_point()</function>.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>The <link linkend="events-pointer-motion-example-4">simple
|
|
scribble application</link> gives a more
|
|
thorough example of how to integrate pointer events into a
|
|
Clutter application (in this case, for drawing on a
|
|
<type>ClutterTexture</type>).</para>
|
|
|
|
<para>The effect of actor depth on pointer motion events is
|
|
worth slightly deeper discussion, and is covered next.</para>
|
|
|
|
<section>
|
|
<title>Pointer events on actors at different depths</title>
|
|
|
|
<para>If you have actors stacked on top of each other, the
|
|
reactive actor nearest the "top" is the one
|
|
which emits the signal (when the pointer crosses into or moves
|
|
over it). "Top" here means either at the top of
|
|
the depth ordering (if all actors are at the same depth)
|
|
or the closest to the view point (if actors have different
|
|
depths in the <code>z</code> axis).</para>
|
|
|
|
<para>Here's an example of three rectangles overlapping each
|
|
other:</para>
|
|
|
|
<screenshot>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata format="PNG"
|
|
fileref="images/events-pointer-motion-stacking.png" />
|
|
</imageobject>
|
|
<alt>
|
|
<para>Pointer events in actors with different depth ordering</para>
|
|
</alt>
|
|
</mediaobject>
|
|
</screenshot>
|
|
|
|
<para>The rectangles are all at the same point on the
|
|
<code>z</code> axis but stacked (different positions in the depth
|
|
order). They have the following properties:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The <emphasis>red</emphasis> rectangle is lowest down
|
|
the depth ordering and reactive. Pointer motion signals are
|
|
emitted by this actor when the pointer crosses or moves on the
|
|
area of the rectangle <emphasis>not</emphasis> overlapped by the
|
|
green rectangle.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The <emphasis>green</emphasis> rectangle is in the
|
|
middle of the depth ordering and reactive. This actor emits
|
|
events over its whole surface, even though it is overlapped
|
|
by the blue rectangle (as the blue rectangle is not
|
|
reactive).</para>
|
|
<para>Even if the blue rectangle were fully opaque, a pointer
|
|
crossing into or moving on the green rectangle's area (even if
|
|
obscured by the blue rectangle) would still cause a signal
|
|
to be emitted.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The <emphasis>blue</emphasis> rectangle is at the top
|
|
of the depth ordering and <emphasis>not</emphasis> reactive.
|
|
This actor doesn't emit any pointer motion signals and doesn't
|
|
block events from occurring on any other actor.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>See <link linkend="events-pointer-motion-example-3">the
|
|
sample code in the appendix</link> for more details.</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Full examples</title>
|
|
|
|
<example id="events-pointer-motion-example-1">
|
|
<title>Simple button with a hover animation (change in opacity
|
|
as the pointer enters and leaves it)</title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-pointer-motion-crossing.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example id="events-pointer-motion-example-2">
|
|
<title>Detecting pointer motion on a <type>ClutterRectangle</type></title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-pointer-motion.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example id="events-pointer-motion-example-3">
|
|
<title>How actors influence pointer events on each other</title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-pointer-motion-stacked.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example id="events-pointer-motion-example-4">
|
|
<title>Scribbling on a <type>ClutterTexture</type> in response
|
|
to pointer events</title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-pointer-motion-scribbler.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section id="events-buttons">
|
|
<title>Making an actor respond to button events</title>
|
|
|
|
<section>
|
|
<title>Problem</title>
|
|
|
|
<para>You want an actor to respond to button events. These might
|
|
be buttons on an input device like a mouse;
|
|
or input events caused by other means, like touches on a screen.</para>
|
|
|
|
<para>Some examples of where this is useful:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>For implementing button widgets which respond to
|
|
button clicks.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>To make actor selections by mouse click (e.g.
|
|
as part of a drawing application).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>To recognise a button press followed by pointer
|
|
motion and button release (e.g. to implement drag
|
|
and drop or kinetic animations).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Solution</title>
|
|
|
|
<para>Connect a handler to the <emphasis>button-press-event</emphasis>
|
|
and/or <emphasis>button-release-event</emphasis> signals of an
|
|
actor.</para>
|
|
|
|
<note>
|
|
<para>The <emphasis>button-press-event</emphasis> is emitted
|
|
when a button is pressed (not necessarily released) on a reactive
|
|
actor; the <emphasis>button-release-event</emphasis> when a
|
|
button is released on a reactive actor (even if the button was
|
|
pressed down somewhere else).</para>
|
|
</note>
|
|
|
|
<para>First, ensure the actor is reactive:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
clutter_actor_set_reactive (actor, TRUE);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Next, create a function to handle the signal(s) you are
|
|
interested in. The function signature is the same for both the
|
|
press and release signals:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
gboolean
|
|
callback_function (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>You can use a single function as the
|
|
callback for both signals (or write a different one for each signal).
|
|
Here's an example function which can be used as a callback
|
|
for both press and release signals, as it simply pulls data
|
|
out of the event and displays it:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
/* <varname>event</varname> is a <type>ClutterButtonEvent</type>
|
|
* for both the press and the release signal; it contains
|
|
* data about where the event occurred
|
|
*/
|
|
static gboolean
|
|
button_event_cb (ClutterActor *actor,
|
|
ClutterEvent *event,
|
|
gpointer user_data)
|
|
{
|
|
gfloat x, y;
|
|
gchar *event_type;
|
|
guint button_pressed;
|
|
ClutterModifierType state;
|
|
gchar *ctrl_pressed;
|
|
guint32 click_count;
|
|
|
|
/* where the pointer was (relative to the stage)
|
|
* when the button event occurred; use
|
|
* <function>clutter_actor_transform_stage_point()</function>
|
|
* to transform to actor-relative coordinates
|
|
*/
|
|
clutter_event_get_coords (event, &x, &y);
|
|
|
|
/* check whether it was a press or release event */
|
|
event_type = "released";
|
|
if (clutter_event_type (event) == CLUTTER_BUTTON_PRESS)
|
|
event_type = "pressed";
|
|
|
|
/* which button triggered the event */
|
|
button_pressed = clutter_event_get_button (event);
|
|
|
|
/* keys down when the event occurred;
|
|
* this is a bit mask composed of the bits for each key held down
|
|
* when the button was pressed or released; see the
|
|
* <type>ClutterModifierType</type> enum in the Clutter API docs
|
|
* for a list of the available modifiers
|
|
*/
|
|
state = clutter_event_get_state (event);
|
|
|
|
ctrl_pressed = "ctrl not pressed";
|
|
if (state & CLUTTER_CONTROL_MASK)
|
|
ctrl_pressed = "ctrl pressed";
|
|
|
|
/* click count */
|
|
click_count = clutter_event_get_click_count (event);
|
|
|
|
g_debug ("button %d was %s at %.0f,%.0f; %s; click count %d",
|
|
button_pressed,
|
|
event_type,
|
|
x,
|
|
y,
|
|
ctrl_pressed,
|
|
click_count);
|
|
|
|
return TRUE;
|
|
}
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Finally, connect the signals to the function(s):</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
/* connect the press event */
|
|
g_signal_connect (actor,
|
|
"button-press-event",
|
|
G_CALLBACK (button_event_cb),
|
|
NULL);
|
|
|
|
/* connect the release event */
|
|
g_signal_connect (actor,
|
|
"button-release-event",
|
|
G_CALLBACK (button_event_cb),
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Pressing or releasing a button on the actor will now
|
|
trigger a call to the <function>button_event_cb()</function>
|
|
function. See <link linkend="events-buttons-example-1">the full
|
|
example</link> for more details.</para>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Discussion</title>
|
|
|
|
<para>Properties of the <type>ClutterButtonEvent</type>
|
|
emitted by both signals should be examined using the
|
|
<function>clutter_event_*</function> functions (rather than struct
|
|
members directly), as in the example above. While most of these
|
|
functions are self-explanatory, a couple require more explanation:
|
|
see the sections below.</para>
|
|
|
|
<para>Also covered below is an alternative approach to handling a
|
|
button press followed by a release on a single actor: by adding
|
|
a <type>ClutterClickAction</type> to an actor. See
|
|
<link linkend="events-buttons-clutterclickaction">this section</link>
|
|
for details.</para>
|
|
|
|
<para>Finally, a <link linkend="events-buttons-example-3">longer
|
|
example</link> is included, showing how to make use of button press,
|
|
button release and pointer events in a simple drawing application.</para>
|
|
|
|
<section>
|
|
<title>Click count</title>
|
|
|
|
<para>The click count records the number of times a press/release
|
|
pair occurred in sequence. You can retrieve it via the
|
|
<function>clutter_event_get_click_count()</function> function.</para>
|
|
|
|
<note>
|
|
<para>A press/release pair is effectively a click, so this term
|
|
will be used from now on throughout this section,
|
|
to make the explanation simpler. However, the click count has
|
|
nothing to do with <type>ClutterClickActions</type>, described
|
|
<link linkend="events-buttons-clutterclickaction">later</link>.
|
|
</para>
|
|
</note>
|
|
|
|
<para>For clicks to be considered part of the same sequence (for
|
|
the purposes of counting), all the clicks after the first one
|
|
must occur within the global <varname>double_click_distance</varname>
|
|
(pixels) of the first click; and the time between click
|
|
<code>n</code> and click <code>n+1</code> must be <code><=</code>
|
|
the global <varname>double_click_time</varname> (milliseconds).</para>
|
|
|
|
<para>The clicks <emphasis>do not</emphasis> have to occur on
|
|
the same actor: providing they occur within the double click
|
|
distance and time, they are counted as part of the same click
|
|
sequence. Also note that the clicks don't even have to happen
|
|
on a reactive actor: providing they happen somewhere on the
|
|
stage, they will still increment the click count.</para>
|
|
|
|
<para>The default double click time and distance are
|
|
stored in the <type>ClutterSettings</type> associated
|
|
with an application. You can get/set their values like this:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
gint double_click_distance;
|
|
gint double_click_time;
|
|
|
|
ClutterSettings *settings = clutter_settings_get_default ();
|
|
|
|
/* get double click settings */
|
|
g_object_get (settings,
|
|
"double-click-distance", &double_click_distance,
|
|
"double-click-time", &double_click_time,
|
|
NULL);
|
|
|
|
/* set */
|
|
g_object_set (settings,
|
|
"double-click-distance", 50,
|
|
"double-click-time", 1000,
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Button numbering</title>
|
|
|
|
<para><function>clutter_event_get_button()</function> returns
|
|
an integer representing the pressed or released button.</para>
|
|
|
|
<para>In the case of a standard scroll mouse, the numbers
|
|
returned are reliable across different hardware models:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>1 = left mouse button</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>2 = scroll wheel</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>3 = right mouse button</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>For mice with more buttons, or other types of
|
|
input devices, the mappings may not be so
|
|
straightforward: you may have to experiment to see
|
|
which button returns which value.</para>
|
|
|
|
</section>
|
|
|
|
<section id="events-buttons-clutterclickaction">
|
|
<title><type>ClutterClickAction</type></title>
|
|
|
|
<para><type>ClutterActions</type> add flexible event handling
|
|
to <type>ClutterActors</type>. They recognise and abstract
|
|
common sequences of low-level events into a single, more easily
|
|
managed high-level event. In the case of a
|
|
<type>ClutterClickAction</type>, the abstraction is over
|
|
a press followed by a release on a single actor. This is
|
|
achieved by "synthesising" the press and release signals on
|
|
the actor: in other words, the action captures those
|
|
two signals when emitted by a single actor; and, once captured, the
|
|
action emits a single <emphasis>clicked</emphasis> signal
|
|
<emphasis>instead</emphasis> of the two signals being
|
|
emitted by the actor.</para>
|
|
|
|
<para>The pointer can move off the actor between the press and
|
|
release, but the press and release must both occur on the same
|
|
actor, with no intervening presses or releases on other
|
|
actors. In addition, there are no maximum distance or time
|
|
constraints on the press and release.</para>
|
|
|
|
<para>If a press occurs and you want to force it to be released
|
|
(e.g. to break a pointer grab after a certain length of
|
|
time has elapsed), use
|
|
<function>clutter_click_action_release()</function>.</para>
|
|
|
|
<para>On the down side, the <emphasis>clicked</emphasis> signal
|
|
doesn't present the same detailed <type>ClutterButtonEvent</type>
|
|
to the handler. So, for example, you can't get a click count from a
|
|
<type>ClutterClickAction</type> (though you could count
|
|
the clicks yourself, of course); and you don't have access
|
|
to the coordinates where the press or release occurred.</para>
|
|
|
|
<para>To add a click action to a <type>ClutterActor</type>:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
ClutterAction *action = clutter_click_action_new ();
|
|
clutter_actor_add_action (actor, action);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<note>
|
|
<para>An actor must still be set to reactive so that its
|
|
signals can be routed to a click action.</para>
|
|
</note>
|
|
|
|
<para>Create a handler function (note the function
|
|
signature is different from the one for the press or
|
|
releas signal handler):</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
void
|
|
clicked_cb (ClutterClickAction *action,
|
|
ClutterActor *actor,
|
|
gpointer user_data)
|
|
{
|
|
/* display the number of the clicked button (equivalent
|
|
* to the number returned by clutter_event_get_button())
|
|
*/
|
|
g_debug ("Button %d clicked", clutter_click_action_get_button (action));
|
|
}
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>Connect the signal to the handler:</para>
|
|
|
|
<informalexample>
|
|
<programlisting>
|
|
g_signal_connect (action,
|
|
"clicked",
|
|
G_CALLBACK (clicked_cb),
|
|
NULL);
|
|
</programlisting>
|
|
</informalexample>
|
|
|
|
<para>The <link linkend="events-buttons-example-2">example
|
|
code</link> gives a bit more detail about how to use click
|
|
actions.</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Full examples</title>
|
|
|
|
<example id="events-buttons-example-1">
|
|
<title>Examining properties of a <type>ClutterButtonEvent</type></title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-buttons.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example id="events-buttons-example-2">
|
|
<title>Using <type>ClutterClickAction</type> to capture
|
|
button events on an actor</title>
|
|
<programlisting>
|
|
<xi:include href="examples/events-buttons-click.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example id="events-buttons-example-3">
|
|
<title>Using button and pointer events for drawing</title>
|
|
<para>This code was inspired by
|
|
<ulink url="http://git.clutter-project.org/cluttersmith/">ClutterSmith</ulink>
|
|
</para>
|
|
<programlisting>
|
|
<xi:include href="examples/events-buttons-lasso.c" parse="text">
|
|
<xi:fallback>a code sample should be here... but isn't</xi:fallback>
|
|
</xi:include>
|
|
</programlisting>
|
|
</example>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
</chapter>
|