mirror of
https://github.com/brl/mutter.git
synced 2024-11-26 18:11:05 -05:00
Merge remote branch 'elliot/cookbook-consistency'
* elliot/cookbook-consistency: cookbook: Fixed typo cookbook: Fix build so CSS files get installed cookbook: Moved paragraph where it logically belongs cookbook: Added some judicious note elements cookbook: Added more information for contributors cookbook: Link out to docbook site cookbook: Made docbook element usage consistent cookbook: Additional selectors in CSS stylesheet cookbook: Copy the CSS file into the HTML build directory
This commit is contained in:
commit
2de61da296
@ -370,6 +370,10 @@ span.application {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
span.property, span.type {
|
||||
font-family: monospace;
|
||||
}
|
||||
|
||||
.programlisting {
|
||||
font-family: monospace;
|
||||
font-size: 80%;
|
||||
|
@ -26,6 +26,7 @@ XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current
|
||||
XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
|
||||
|
||||
HTML_FILES = html/*.html
|
||||
CSS_FILES = html/*.css
|
||||
IMAGE_FILES = images/clutter-logo.png
|
||||
|
||||
EXTRA_DIST = clutter-cookbook.xml.in $(IMAGE_FILES) $(XML_FILES)
|
||||
@ -43,6 +44,7 @@ pdf-build.stamp: clutter-cookbook.xml
|
||||
html-build.stamp: clutter-cookbook.xml
|
||||
$(XSLTPROC) $(XSLTOPTS) -o clutter-cookbook.html $(XSL_XHTML_URI) $(top_builddir)/doc/cookbook/clutter-cookbook.xml && \
|
||||
$(XSLTPROC) $(XSLTOPTS) -o html/ ref-html-style.xsl $(top_builddir)/doc/cookbook/clutter-cookbook.xml && \
|
||||
cp $(top_srcdir)/doc/common/style.css html/ && \
|
||||
echo timestamp > $(@F)
|
||||
|
||||
if ENABLE_PDFS
|
||||
@ -71,7 +73,7 @@ install-data-local:
|
||||
then echo '-- Nothing to install' ; \
|
||||
else \
|
||||
$(mkinstalldirs) $(DESTDIR)$(TARGET_DIR) ; \
|
||||
for file in `ls $(HTML_FILES)`; do \
|
||||
for file in `ls $(HTML_FILES) $(CSS_FILES)`; do \
|
||||
if [ -f $$file ]; then \
|
||||
basefile=`echo $$file | sed -e 's,^.*/,,'`; \
|
||||
$(INSTALL_DATA) $$file $(DESTDIR)$(TARGET_DIR)/$$basefile; \
|
||||
@ -89,7 +91,6 @@ install-data-local:
|
||||
fi \
|
||||
done; \
|
||||
fi; \
|
||||
$(INSTALL_DATA) $(top_srcdir)/doc/common/style.css $(DESTDIR)$(TARGET_DIR)/style.css; \
|
||||
$(INSTALL_DATA) html/clutter-cookbook.devhelp $(DESTDIR)$(TARGET_DIR)/clutter-cookbook.devhelp
|
||||
|
||||
.PHONY : doc
|
||||
|
@ -23,7 +23,7 @@
|
||||
with the others: it can be the parent of another actor, or a child of
|
||||
another actor.</para>
|
||||
|
||||
<note><para>The Stage is an actor that can have children but cannot have
|
||||
<note><para>The stage is an actor that can have children but cannot have
|
||||
any parent.</para></note>
|
||||
|
||||
<para>Actors have different attributes: a position, a size, a
|
||||
@ -38,7 +38,7 @@
|
||||
</section>
|
||||
|
||||
<section id="actors-allocation-notify">
|
||||
<title>Knowing when an actor position or size change</title>
|
||||
<title>Knowing when an actor's position or size changes</title>
|
||||
|
||||
<section>
|
||||
<title>Problem</title>
|
||||
@ -112,7 +112,9 @@ on_allocation_changed (ClutterActor *actor,
|
||||
|
||||
<para>Any change the position and size of an actor will cause a
|
||||
change in the allocation of the actor itself. This will update the
|
||||
values of the :x, :y, :width and :height properties as well.</para>
|
||||
values of the <property>x</property>, <property>y</property>,
|
||||
<property>width</property> and <property>height</property>
|
||||
properties as well.</para>
|
||||
|
||||
<para>The first technique allows a greater deal of granularity,
|
||||
allowing you to know what exactly changed. Inside the callback
|
||||
@ -159,12 +161,13 @@ on_allocation_changed (ClutterActor *actor,
|
||||
<para>All actors will update these properties when their size
|
||||
or position change.</para>
|
||||
|
||||
<para>Note that the Stage, on the other hand, will not notify on
|
||||
position changes, so it is not possible to use the :x and :y
|
||||
<para>Note that the stage, on the other hand, will not notify on
|
||||
position changes, so it is not possible to use the
|
||||
<property>x</property> and <property>y</property>
|
||||
properties to know that the platform-specific window embedding the
|
||||
stage has been moved — if the platform supports a windowing
|
||||
system. In order to achieve that you will have to use backend-specific
|
||||
API to extract the surface used by the Stage and then platform-specific
|
||||
API to extract the surface used by the stage and then platform-specific
|
||||
API to retrieve its coordinates.</para>
|
||||
|
||||
</section>
|
||||
@ -218,11 +221,11 @@ void on_paint (ClutterActor *actor, gpointer user_data);
|
||||
<title>Discussion</title>
|
||||
|
||||
<para>The paint cycle in Clutter works its way recursively from the
|
||||
Stage through every child.</para>
|
||||
stage through every child.</para>
|
||||
|
||||
<para>Whenever an Actor is going to be painted it will be positioned in
|
||||
a new frame of reference according to the list of transformations
|
||||
(scaling, rotation and additional traslations). After that, the "paint"
|
||||
(scaling, rotation and additional translations). After that, the "paint"
|
||||
signal will be emitted.</para>
|
||||
|
||||
<para>The "paint" signal is defined as <emphasis>run-last</emphasis>,
|
||||
@ -255,4 +258,3 @@ on_paint (ClutterActor *actor)
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
@ -49,9 +49,64 @@
|
||||
<appendix id="contributing">
|
||||
<title>Contributing to this document</title>
|
||||
|
||||
<para>This document is written in Docbook XML. The source file for this
|
||||
document is located in the subdirectory "doc/cookbook" of the source
|
||||
directory of Clutter.</para>
|
||||
<para>This document is written in
|
||||
<ulink url="http://docbook.org/">Docbook XML</ulink>. The source files
|
||||
for this document are located in the subdirectory
|
||||
<filename>doc/cookbook</filename> inside the Clutter source directory.</para>
|
||||
|
||||
<para>To maintain some degree of consistency, try to stick to the
|
||||
following broad guidelines about how to write Docbook for this
|
||||
cookbook:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>If adding a new recipe, use the
|
||||
<filename>recipe-template.xml</filename> XML file as a basis.
|
||||
You can find it in the <filename><clutter_source>/doc/cookbook/</filename>
|
||||
directory.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Try to indent your XML sensibly using 2 spaces per level
|
||||
(we're not too strict, but some indentation helps reading
|
||||
the source).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Stick to a column width of around 80 characters.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <filename> element for file
|
||||
and directory names.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <property> element for property names
|
||||
(e.g. GObject properties).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <type> element for GObject class
|
||||
names.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <constant> element for C defines.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <keycap> element for keys, where
|
||||
you are referring to what's actually printed on the key, e.g.
|
||||
<keycap>Shift</keycap>. If you're referring to the key some
|
||||
other way (e.g. "the Control key"), don't use
|
||||
<keycap>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <function> element for functions;
|
||||
the style adopted is to give the function name followed by
|
||||
empty brackets, e.g. <function>clutter_actor_set_size()</function>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use the <note> element for asides which might
|
||||
otherwise interrupt the flow of the recipe.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</appendix>
|
||||
|
||||
</book>
|
||||
|
@ -70,8 +70,8 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Solution 2:</emphasis> Use an actor's
|
||||
ClutterBindingPool to declaratively assign actions to specific
|
||||
key and modifier combinations.</para>
|
||||
<type>ClutterBindingPool</type> to declaratively assign
|
||||
actions to specific key and modifier combinations.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
@ -80,12 +80,13 @@
|
||||
<section>
|
||||
<title>Solution 1</title>
|
||||
|
||||
<para>Connect the key-press-event signal for an actor to a callback;
|
||||
then examine the event in the callback to determine which key and
|
||||
modifiers were pressed.</para>
|
||||
<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 key-press-event signal
|
||||
to a callback:</para>
|
||||
<para>First, connect an actor's
|
||||
<emphasis>key-press-event</emphasis> signal to a callback:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -96,7 +97,8 @@ g_signal_connect (actor, "key-press-event", G_CALLBACK (_key_press_cb), NULL);
|
||||
<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 Shift and/or Control key were down:</para>
|
||||
the <keycap>Shift</keycap> and/or <keycap>Ctrl</keycap>
|
||||
key were down:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -136,34 +138,41 @@ _key_press_cb (ClutterActor *actor,
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Note that Clutter provides a range of key value definitions
|
||||
(like CLUTTER_Up, used above). These are generated from the list in the
|
||||
<note>
|
||||
<para>Clutter provides a range of key value definitions
|
||||
(like <constant>CLUTTER_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" in the definitions there to get the
|
||||
CLUTTER equivalents; alternatively, look at the clutter-keysyms.h
|
||||
header file for the list).</para>
|
||||
CLUTTER equivalents; alternatively, look at the
|
||||
<filename>clutter-keysyms.h</filename> header file for the
|
||||
list).</para>
|
||||
|
||||
<para>CLUTTER_SHIFT_MASK, CLUTTER_CONTROL_MASK and other modifiers are
|
||||
defined in the ClutterModifierType enum.</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 ClutterBindingPool.
|
||||
<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 Discussion section for
|
||||
more details.</para>
|
||||
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 ClutterStage:</para>
|
||||
we're using the binding pool for the default
|
||||
<type>ClutterStage</type>:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -176,8 +185,9 @@ binding_pool = clutter_binding_pool_get_for_class (stage_class);
|
||||
</informalexample>
|
||||
|
||||
<para>Next, install actions into the binding pool. For example, to
|
||||
install an action bound to the up arrow key, which calls the _move_up
|
||||
function when that key is pressed, you would do:</para>
|
||||
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>
|
||||
@ -191,8 +201,10 @@ clutter_binding_pool_install_action (binding_pool,
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Another example, binding up + Shift + Control to an action which
|
||||
calls _move_up_shift_control when activated:</para>
|
||||
<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>
|
||||
@ -206,8 +218,8 @@ clutter_binding_pool_install_action (binding_pool,
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>The function called when an action is activated looks like this
|
||||
(for _move_up):</para>
|
||||
<para>The function called when an action is activated looks
|
||||
like this (for <function>_move_up()</function>):</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -223,8 +235,8 @@ _move_up (GObject *instance,
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Then bind the key-press-event for the actor (in our case,
|
||||
the stage) to a callback:</para>
|
||||
<para>Then bind the <emphasis>key-press-event</emphasis> signal
|
||||
for the actor (in our case, the stage) to a callback:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -258,13 +270,13 @@ _key_press_cb (ClutterActor *actor,
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, when a key plus modifiers that has been bound to an action
|
||||
is pressed on the actor, the appropriate action is activated.</para>
|
||||
<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>
|
||||
<section id="events-handling-key-events-discussion">
|
||||
<title>Discussion</title>
|
||||
|
||||
<section>
|
||||
@ -285,9 +297,10 @@ _key_press_cb (ClutterActor *actor,
|
||||
|
||||
<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 clutter_binding_pool_find (as in the example code) to determine
|
||||
which binding pool to activate (depending on which actor received the
|
||||
key press event).</para>
|
||||
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
|
||||
@ -305,17 +318,19 @@ _key_press_cb (ClutterActor *actor,
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A ClutterKeyEvent contains only a <emphasis>single</emphasis>
|
||||
key value, plus possibly one or more modifier keys (like Shift,
|
||||
Control, Alt etc.). There are no functions in the
|
||||
Clutter API which return events for tracking near-simultaneous
|
||||
presses on multiple keys.</para>
|
||||
<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
|
||||
clutter_stage_set_key_focus:</para>
|
||||
<function>clutter_stage_set_key_focus()</function>:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
|
@ -27,8 +27,8 @@
|
||||
<section>
|
||||
<title>Solution</title>
|
||||
|
||||
<para>Create a ClutterCairoTexture, then draw onto the Cairo context
|
||||
it wraps using the Cairo API:</para>
|
||||
<para>Create a <type>ClutterCairoTexture</type>, then draw onto
|
||||
the Cairo context it wraps using the Cairo API:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -64,9 +64,11 @@ cairo_destroy (cr);
|
||||
<section>
|
||||
<title>Discussion</title>
|
||||
|
||||
<para>A ClutterCairoTexture is a standard ClutterActor, so it can be
|
||||
added to ClutterContainers (e.g. a ClutterStage or ClutterGroup),
|
||||
animated, resized etc. in the usual ways.</para>
|
||||
<para>A <type>ClutterCairoTexture</type> is a standard
|
||||
<type>ClutterActor</type>, so it can be added to a
|
||||
<type>ClutterContainer</type> (e.g. a <type>ClutterStage</type>
|
||||
or <type>ClutterGroup</type>), animated, resized etc. in the
|
||||
usual ways.</para>
|
||||
|
||||
<para>Other useful operations:</para>
|
||||
|
||||
@ -74,24 +76,24 @@ cairo_destroy (cr);
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>To draw on part of the texture:</emphasis>
|
||||
use <function>clutter_cairo_texture_create_region</function> to
|
||||
use <function>clutter_cairo_texture_create_region()</function> to
|
||||
retrieve a Cairo context for the region you want to draw on.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>To clear existing content from a texture:</emphasis>
|
||||
use <function>clutter_cairo_texture_clear</function>.</para>
|
||||
use <function>clutter_cairo_texture_clear()</function>.</para>
|
||||
|
||||
<para>You may need to do this as the texture reuses the same
|
||||
Cairo context each time you call
|
||||
<function>clutter_cairo_texture_create</function> or
|
||||
<function>clutter_cairo_texture_create_region</function>.</para>
|
||||
<function>clutter_cairo_texture_create()</function> or
|
||||
<function>clutter_cairo_texture_create_region()</function>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>To resize the Cairo context wrapped
|
||||
by a texture</emphasis>, use
|
||||
<function>clutter_cairo_texture_set_surface_size</function>.</para>
|
||||
<function>clutter_cairo_texture_set_surface_size()</function>.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
@ -144,13 +146,14 @@ cairo_destroy (cr);
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Note that if the page is larger than the Cairo context,
|
||||
some of it might not be visible. Similarly, if the ClutterCairoTexture
|
||||
is larger than the stage, some of that might not be visible. So you
|
||||
may need to do some work to make the ClutterCairoTexture fit
|
||||
inside the stage properly (e.g. resize the stage), and/or some work
|
||||
<note><para>If the page is larger than the Cairo context,
|
||||
some of it might not be visible. Similarly, if the
|
||||
<type>ClutterCairoTexture</type> is larger than the stage,
|
||||
some of that might not be visible. So you
|
||||
may need to do some work to make the <type>ClutterCairoTexture</type>
|
||||
fit inside the stage properly (e.g. resize the stage), and/or some work
|
||||
to make the PDF page sit inside the Cairo context (e.g. scale the PDF
|
||||
page or put it inside a scrollable actor).</para>
|
||||
page or put it inside a scrollable actor).</para></note>
|
||||
|
||||
</section>
|
||||
|
||||
@ -174,8 +177,8 @@ cairo_destroy (cr);
|
||||
|
||||
<para>Set the texture to keep the aspect ratio of the
|
||||
underlying image (so it doesn't distort when it's scaled); use
|
||||
the actor's request-mode property to set the correct
|
||||
geometry management (see the discussion section); then
|
||||
the actor's <property>request-mode</property> property to set
|
||||
the correct geometry management (see the discussion section); then
|
||||
resize the texture along one dimension (height or width).
|
||||
Now, when an image is loaded into the texture, the image is
|
||||
scaled to fit the set height or width; the other dimension
|
||||
@ -210,20 +213,20 @@ clutter_texture_set_from_file (CLUTTER_TEXTURE (texture),
|
||||
<section>
|
||||
<title>Discussion</title>
|
||||
|
||||
<para>The request mode for an actor determines how
|
||||
geometry requisition is performed; in this case, this
|
||||
<para>The <property>request-mode</property> for an actor
|
||||
determines how geometry requisition is performed; in this case, this
|
||||
includes how scaling is applied if you change the actor's
|
||||
width or height. There are two possible values for
|
||||
request-mode:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>If set to <emphasis>CLUTTER_REQUEST_HEIGHT_FOR_WIDTH</emphasis>
|
||||
<para>If set to <constant>CLUTTER_REQUEST_HEIGHT_FOR_WIDTH</constant>
|
||||
(the default), changing the width causes the height
|
||||
to be scaled by the same factor as the width.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If set to <emphasis>CLUTTER_REQUEST_WIDTH_FOR_HEIGHT</emphasis>,
|
||||
<para>If set to <constant>CLUTTER_REQUEST_WIDTH_FOR_HEIGHT</constant>,
|
||||
changing the height causes the width to be scaled by the
|
||||
same factor as the height.</para>
|
||||
</listitem>
|
||||
@ -231,21 +234,22 @@ clutter_texture_set_from_file (CLUTTER_TEXTURE (texture),
|
||||
|
||||
<para>In the example above, the texture is set to keep its
|
||||
aspect ratio then fixed to a width of 300 pixels; the
|
||||
request-mode is set to CLUTTER_REQUEST_HEIGHT_FOR_WIDTH. If a
|
||||
standard, photo-sized image in landscape orientation were
|
||||
request-mode is set to <constant>CLUTTER_REQUEST_HEIGHT_FOR_WIDTH</constant>.
|
||||
If a standard, photo-sized image in landscape orientation were
|
||||
loaded into it (2848 pixels wide x 2136 high), it would be scaled
|
||||
down to 300 pixels wide; then, its height would be scaled by the
|
||||
same factor as the width (i.e. scaled down to 225 pixels).</para>
|
||||
|
||||
<para>With request-mode set to CLUTTER_REQUEST_WIDTH_FOR_HEIGHT,
|
||||
<para>With request-mode set to
|
||||
<constant>CLUTTER_REQUEST_WIDTH_FOR_HEIGHT</constant>,
|
||||
you would get the same effect by setting the height first;
|
||||
then, computation of the width for the scaled image would be
|
||||
based on the scaling factor applied to its height instead.</para>
|
||||
|
||||
<para>You can work out which side of the source image is longest using
|
||||
clutter_texture_base_size() to get its width and height. This can
|
||||
be useful when trying to scale images with different orientations
|
||||
to fit into uniform rows or columns:</para>
|
||||
<function>clutter_texture_base_size()</function> to get its
|
||||
width and height. This can be useful when trying to scale images
|
||||
with different orientations to fit into uniform rows or columns:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -259,8 +263,9 @@ clutter_texture_get_base_size (CLUTTER_TEXTURE (texture), &width, &height);
|
||||
</informalexample>
|
||||
|
||||
<note><para>If you explicitly set the size (both width and height)
|
||||
of a texture with clutter_actor_set_size() (or
|
||||
with clutter_actor_set_width() and clutter_actor_set_height()), any
|
||||
of a texture with <function>clutter_actor_set_size()</function> (or
|
||||
with <function>clutter_actor_set_width()</function> and
|
||||
<function>clutter_actor_set_height()</function>), any
|
||||
image loaded into the texture is automatically stretched/shrunk to
|
||||
fit the texture. This is the case regardless of any other settings
|
||||
(like whether to keep aspect ratio).</para></note>
|
||||
@ -285,7 +290,8 @@ clutter_texture_get_base_size (CLUTTER_TEXTURE (texture), &width, &height);
|
||||
<section>
|
||||
<title>Solution</title>
|
||||
|
||||
<para>Create a ClutterTexture directly from an image file:</para>
|
||||
<para>Create a <type>ClutterTexture</type> directly from an
|
||||
image file:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
@ -378,11 +384,12 @@ if (error != NULL)
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Call g_thread_init() (from the GLib library) prior
|
||||
to calling clutter_init(), so that a local thread is used
|
||||
to load the file, rather than the main loop. (Note that
|
||||
this is not necessary if you're using GLib version >= 2.24,
|
||||
since GObject initializes threading with the type system.)</para>
|
||||
<para>Call <function>g_thread_init()</function> (from the
|
||||
GLib library) prior to calling <function>clutter_init()</function>,
|
||||
so that a local thread is used to load the file, rather
|
||||
than the main loop. (Note that this is not necessary if
|
||||
you're using GLib version >= 2.24, since GObject
|
||||
initializes threading with the type system.)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Set the texture to load data asynchronously.</para>
|
||||
@ -462,16 +469,18 @@ main (int argc, char *argv[])
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Various GNOME libraries provide image data in GdkPixbuf
|
||||
structures; clutter-gtk has functions for
|
||||
creating or setting a texture from a GdkPixbuf:
|
||||
gtk_clutter_texture_new_from_pixbuf()
|
||||
and gtk_clutter_texture_set_from_pixbuf() respectively.</para>
|
||||
<para>Various GNOME libraries provide image data in
|
||||
<type>GdkPixbuf</type> structures; clutter-gtk has
|
||||
functions for creating or setting a texture from a
|
||||
<type>GdkPixbuf</type>:
|
||||
<function>gtk_clutter_texture_new_from_pixbuf()</function>
|
||||
and <function>gtk_clutter_texture_set_from_pixbuf()</function>
|
||||
respectively.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If you have raw RGB pixel data, ClutterTexture also has
|
||||
the clutter_texture_set_from_rgb_data() method for loading
|
||||
it.</para>
|
||||
<para>If you have raw RGB pixel data, <type>ClutterTexture</type>
|
||||
also has a <function>clutter_texture_set_from_rgb_data()</function>
|
||||
function for loading it.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user