isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-27 02:20:43 -05:00
Code Issues Packages Projects Releases Wiki Activity
72b523c9e9
mutter/clutter/clutter-layout-manager.c

1391 lines
48 KiB
C
Raw Normal View History

[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
/*
* Clutter.
*
* An OpenGL based 'interactive canvas' library.
*
* Copyright (C) 2009 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
* Author:
* Emmanuele Bassi <ebassi@linux.intel.com>
*/
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
/**
* SECTION:clutter-layout-manager
* @short_description: Layout managers base class
*
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
* #ClutterLayoutManager is a base abstract class for layout managers. A
* layout manager implements the layouting policy for a composite or a
* container actor: it controls the preferred size of the actor to which
* it has been paired, and it controls the allocation of its children.
*
* Any composite or container #ClutterActor subclass can delegate the
* layouting of its children to a #ClutterLayoutManager. Clutter provides
* a generic container using #ClutterLayoutManager called #ClutterBox.
*
* Clutter provides some simple #ClutterLayoutManager sub-classes, like
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* #ClutterFlowLayout and #ClutterBinLayout.
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
*
layout, docs: Add more documentation to LayoutManager The layout manager reference should have some documentation on how to use a LayoutManager object inside a container and how to implement a LayoutManager sub-class correctly.
2009-10-19 06:00:23 -04:00
* <refsect2 id="ClutterLayoutManager-use-in-Actor">
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* <title>Using a Layout Manager inside an Actor</title>
layout, docs: Add more documentation to LayoutManager The layout manager reference should have some documentation on how to use a LayoutManager object inside a container and how to implement a LayoutManager sub-class correctly.
2009-10-19 06:00:23 -04:00
* <para>In order to use a #ClutterLayoutManager inside a #ClutterActor
* sub-class you should invoke clutter_layout_manager_get_preferred_width()
* inside the <structname>ClutterActor</structname>::get_preferred_width()
* virtual function and clutter_layout_manager_get_preferred_height()
* inside the <structname>ClutterActor</structname>::get_preferred_height()
* virtual function implementations. You should also call
* clutter_layout_manager_allocate() inside the implementation of the
* <structname>ClutterActor</structname>::allocate() virtual
* function.</para>
* <para>In order to receive notifications for changes in the layout
* manager policies you should also connect to the
* #ClutterLayoutManager::layout-changed signal and queue a relayout
* on your actor. The following code should be enough if the actor
* does not need to perform specific operations whenever a layout
* manager changes:</para>
* <informalexample><programlisting>
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* g_signal_connect_swapped (layout_manager,
* "layout-changed",
* G_CALLBACK (clutter_actor_queue_relayout),
* actor);
layout, docs: Add more documentation to LayoutManager The layout manager reference should have some documentation on how to use a LayoutManager object inside a container and how to implement a LayoutManager sub-class correctly.
2009-10-19 06:00:23 -04:00
* </programlisting></informalexample>
* </refsect2>
*
* <refsect2 id="ClutterLayoutManager-implementation">
* <title>Implementing a ClutterLayoutManager</title>
* <para>The implementation of a layout manager does not differ from
* the implementation of the size requisition and allocation bits of
* #ClutterActor, so you should read the relative documentation
docs: Reword a link
2009-10-19 06:44:29 -04:00
* <link linkend="clutter-subclassing-ClutterActor">for subclassing
* ClutterActor</link>.</para>
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* <para>The layout manager implementation can hold a back pointer
* to the #ClutterContainer by implementing the
* <function>set_container()</function> virtual function. The layout manager
* should not hold a real reference (i.e. call g_object_ref()) on the
* container actor, to avoid reference cycles.</para>
docs: Improve documentation of LayoutManager Especially with regards to layout properties and their usage inside a ClutterScript UI definition.
2011-10-17 06:48:47 -04:00
* <para>If a layout manager has properties affecting the layout
layout, docs: Add more documentation to LayoutManager The layout manager reference should have some documentation on how to use a LayoutManager object inside a container and how to implement a LayoutManager sub-class correctly.
2009-10-19 06:00:23 -04:00
* policies then it should emit the #ClutterLayoutManager::layout-changed
* signal on itself by using the clutter_layout_manager_layout_changed()
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* function whenever one of these properties changes.</para>
layout, docs: Add more documentation to LayoutManager The layout manager reference should have some documentation on how to use a LayoutManager object inside a container and how to implement a LayoutManager sub-class correctly.
2009-10-19 06:00:23 -04:00
* </refsect2>
*
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
* <refsect2 id="ClutterLayoutManager-animation">
* <title>Animating a ClutterLayoutManager</title>
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* <para>A layout manager is used to let a #ClutterContainer take complete
* ownership over the layout (that is: the position and sizing) of its
* children; this means that using the Clutter animation API, like
* clutter_actor_animate(), to animate the position and sizing of a child of
* a layout manager it is not going to work properly, as the animation will
* automatically override any setting done by the layout manager
* itself.</para>
* <para>It is possible for a #ClutterLayoutManager sub-class to animate its
* children layout by using the base class animation support. The
* #ClutterLayoutManager animation support consists of three virtual
* functions: <function>begin_animation()</function>,
* <function>get_animation_progress()</function> and
* <function>end_animation()</function>.</para>
* <variablelist>
* <varlistentry>
* <term><function>begin_animation (duration, easing)</function></term>
* <listitem><para>This virtual function is invoked when the layout
* manager should begin an animation. The implementation should set up
* the state for the animation and create the ancillary objects for
* animating the layout. The default implementation creates a
* #ClutterTimeline for the given duration and a #ClutterAlpha binding
* the timeline to the given easing mode. This function returns a
* #ClutterAlpha which should be used to control the animation from
* the caller perspective.</para></listitem>
* </varlistentry>
* <varlistentry>
* <term><function>get_animation_progress()</function></term>
* <listitem><para>This virtual function should be invoked when animating
* a layout manager. It returns the progress of the animation, using the
* same semantics as the #ClutterAlpha:alpha value.</para></listitem>
* </varlistentry>
* <varlistentry>
* <term><function>end_animation()</function></term>
* <listitem><para>This virtual function is invoked when the animation of
* a layout manager ends, and it is meant to be used for bookkeeping the
* objects created in the <function>begin_animation()</function>
* function. The default implementation will call it implicitly when the
* timeline is complete.</para></listitem>
* </varlistentry>
* </variablelist>
* <para>The simplest way to animate a layout is to create a #ClutterTimeline
* inside the <function>begin_animation()</function> virtual function, along
* with a #ClutterAlpha, and for each #ClutterTimeline::new-frame signal
* emission call clutter_layout_manager_layout_changed(), which will cause a
* relayout. The #ClutterTimeline::completed signal emission should cause
* clutter_layout_manager_end_animation() to be called. The default
* implementation provided internally by #ClutterLayoutManager does exactly
* this, so most sub-classes should either not override any animation-related
* virtual function or simply override <function>begin_animation()</function>
* and <function>end_animation()</function> to set up ad hoc state, and then
* chain up to the parent's implementation.</para>
* <example id="example-ClutterLayoutManager-animation">
* <title>Animation of a Layout Manager</title>
* <para>The code below shows how a #ClutterLayoutManager sub-class should
* provide animating the allocation of its children from within the
* <function>allocate()</function> virtual function implementation. The
* animation is computed between the last stable allocation performed
* before the animation started and the desired final allocation.</para>
* <para>The <varname>is_animating</varname> variable is stored inside the
* #ClutterLayoutManager sub-class and it is updated by overriding the
* <function>begin_animation()</function> and
* <function>end_animation()</function> virtual functions and chaining up
* to the base class implementation.</para>
* <para>The last stable allocation is stored within a #ClutterLayoutMeta
* sub-class used by the implementation.</para>
* <programlisting>
* static void
* my_layout_manager_allocate (ClutterLayoutManager *manager,
* ClutterContainer *container,
* const ClutterActorBox *allocation,
* ClutterAllocationFlags flags)
* {
* MyLayoutManager *self = MY_LAYOUT_MANAGER (manager);
Drop some more ClutterContainer.get_children() uses
2011-12-18 17:35:45 -05:00
* ClutterActor *child;
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
*
Drop some more ClutterContainer.get_children() uses
2011-12-18 17:35:45 -05:00
* for (child = clutter_actor_get_first_child (CLUTTER_ACTOR (container));
* child != NULL;
* child = clutter_actor_get_next_sibling (child))
layout-manager: Document the animation support Add a section inside the LayoutManager class API reference documenting, with examples, how to implement animation support inside a layout manager sub-class.
2009-12-23 05:35:16 -05:00
* {
* ClutterLayoutMeta *meta;
* MyLayoutMeta *my_meta;
*
* /&ast; retrieve the layout meta-object &ast;/
* meta = clutter_layout_manager_get_child_meta (manager,
* container,
* child);
* my_meta = MY_LAYOUT_META (meta);
*
* /&ast; compute the desired allocation for the child &ast;/
* compute_allocation (self, my_meta, child,
* allocation, flags,
* &amp;child_box);
*
* /&ast; this is the additional code that deals with the animation
* &ast; of the layout manager
* &ast;/
* if (!self-&gt;is_animating)
* {
* /&ast; store the last stable allocation for later use &ast;/
* my_meta-&gt;last_alloc = clutter_actor_box_copy (&amp;child_box);
* }
* else
* {
* ClutterActorBox end = { 0, };
* gdouble p;
*
* /&ast; get the progress of the animation &ast;/
* p = clutter_layout_manager_get_animation_progress (manager);
*
* if (my_meta-&gt;last_alloc != NULL)
* {
* /&ast; copy the desired allocation as the final state &ast;/
* end = child_box;
*
* /&ast; then interpolate the initial and final state
* &ast; depending on the progress of the animation,
* &ast; and put the result inside the box we will use
* &ast; to allocate the child
* &ast;/
* clutter_actor_box_interpolate (my_meta-&gt;last_alloc,
* &amp;end,
* p,
* &amp;child_box);
* }
* else
* {
* /&ast; if there is no stable allocation then the child was
* &ast; added while animating; one possible course of action
* &ast; is to just bail out and fall through to the allocation
* &ast; to position the child directly at its final state
* &ast;/
* my_meta-&gt;last_alloc =
* clutter_actor_box_copy (&amp;child_box);
* }
* }
*
* /&ast; allocate the child &ast;/
* clutter_actor_allocate (child, &child_box, flags);
* }
* }
* </programlisting>
* </example>
* <para>Sub-classes of #ClutterLayoutManager that support animations of the
* layout changes should call clutter_layout_manager_begin_animation()
* whenever a layout property changes value, e.g.:</para>
* <informalexample>
* <programlisting>
* if (self->orientation != new_orientation)
* {
* ClutterLayoutManager *manager;
*
* self->orientation = new_orientation;
*
* manager = CLUTTER_LAYOUT_MANAGER (self);
* clutter_layout_manager_layout_changed (manager);
* clutter_layout_manager_begin_animation (manager, 500, CLUTTER_LINEAR);
*
* g_object_notify (G_OBJECT (self), "orientation");
* }
* </programlisting>
* </informalexample>
* <para>The code above will animate a change in the
* <varname>orientation</varname> layout property of a layout manager.</para>
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
* </refsect2>
*
docs: Improve documentation of LayoutManager Especially with regards to layout properties and their usage inside a ClutterScript UI definition.
2011-10-17 06:48:47 -04:00
* <refsect2 id="clutter-layout-properties">
* <title>Layout Properties</title>
* <para>If a layout manager has layout properties, that is properties that
* should exist only as the result of the presence of a specific (layout
* manager, container actor, child actor) combination, and it wishes to store
* those properties inside a #ClutterLayoutMeta, then it should override the
* <structname>ClutterLayoutManager</structname>::get_child_meta_type()
* virtual function to return the #GType of the #ClutterLayoutMeta sub-class
* used to store the layout properties; optionally, the #ClutterLayoutManager
* sub-class might also override the
* <structname>ClutterLayoutManager</structname>::create_child_meta() virtual
* function to control how the #ClutterLayoutMeta instance is created,
* otherwise the default implementation will be equivalent to:</para>
* <informalexample><programlisting>
* ClutterLayoutManagerClass *klass;
* GType meta_type;
*
* klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
* meta_type = klass->get_child_meta_type (manager);
*
* return g_object_new (meta_type,
* "manager", manager,
* "container", container,
* "actor", actor,
* NULL);
* </programlisting></informalexample>
* <para>Where <varname>manager</varname> is the #ClutterLayoutManager,
* <varname>container</varname> is the #ClutterContainer using the
* #ClutterLayoutManager and <varname>actor</varname> is the #ClutterActor
* child of the #ClutterContainer.</para>
* </refsect2>
*
* <refsect2 id="clutter-layout-script">
* <title>Using ClutterLayoutManager with ClutterScript</title>
* <para>#ClutterLayoutManager instance can be created in the same way
* as other objects in #ClutterScript; properties can be set using the
* common syntax.</para>
* <para>Layout properties can be set on children of a container with
* a #ClutterLayoutManager using the <emphasis>layout::</emphasis>
* modifier on the property name, for instance:</para>
* <informalexample><programlisting>
* {
* "type" : "ClutterBox",
* "layout-manager" : { "type" : "ClutterTableLayout" },
* "children" : [
* {
* "type" : "ClutterTexture",
* "filename" : "image-00.png",
*
* "layout::row" : 0,
* "layout::column" : 0,
* "layout::x-align" : "left",
* "layout::y-align" : "center",
* "layout::x-expand" : true,
* "layout::y-expand" : true
* },
* {
* "type" : "ClutterTexture",
* "filename" : "image-01.png",
*
* "layout::row" : 0,
* "layout::column" : 1,
* "layout::x-align" : "right",
* "layout::y-align" : "center",
* "layout::x-expand" : true,
* "layout::y-expand" : true
* }
* ]
* }
* </programlisting></informalexample>
* </refsect2>
*
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
* #ClutterLayoutManager is available since Clutter 1.2
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
#include <glib-object.h>
#include <gobject/gvaluecollector.h>
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
#include "clutter-alpha.h"
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
#include "clutter-debug.h"
#include "clutter-layout-manager.h"
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
#include "clutter-layout-meta.h"
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
#include "clutter-marshal.h"
#include "clutter-private.h"
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
#include "clutter-timeline.h"
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
#define LAYOUT_MANAGER_WARN_NOT_IMPLEMENTED(m,method) G_STMT_START { \
GObject *_obj = G_OBJECT (m); \
g_warning ("Layout managers of type %s do not implement " \
"the ClutterLayoutManager::%s method", \
G_OBJECT_TYPE_NAME (_obj), \
(method)); } G_STMT_END
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
enum
{
LAYOUT_CHANGED,
LAST_SIGNAL
};
[layout] Make LayoutManager a floating object A layout manager instance makes only sense if it's owned by a container. For this reason, it should have a floating reference instead of a full reference on construction; this allows constructing Boxes like: box = clutter_box_new (clutter_fixed_layout_new ()); without leaking the layout manager instance.
2009-09-02 06:55:22 -04:00
G_DEFINE_ABSTRACT_TYPE (ClutterLayoutManager,
clutter_layout_manager,
G_TYPE_INITIALLY_UNOWNED);
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
static GQuark quark_layout_meta = 0;
static GQuark quark_layout_alpha = 0;
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
static guint manager_signals[LAST_SIGNAL] = { 0, };
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
static void
layout_manager_freeze_layout_change (ClutterLayoutManager *manager)
{
gpointer is_frozen;
layout-manager: Do not emit layout-changed on thaw When thawing a LayoutManager, do not emit the ::layout-changed signal since it might still be in the middle of a relayout. http://bugzilla.clutter-project.org/show_bug.cgi?id=2255
2010-08-09 06:06:44 -04:00
CLUTTER_NOTE (LAYOUT, "Freezing changes for manager '%s'[%p]",
G_OBJECT_TYPE_NAME (manager),
manager);
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
is_frozen = g_object_get_data (G_OBJECT (manager), "freeze-change");
if (is_frozen == NULL)
g_object_set_data (G_OBJECT (manager), "freeze-change",
GUINT_TO_POINTER (1));
else
{
guint level = GPOINTER_TO_UINT (is_frozen) + 1;
g_object_set_data (G_OBJECT (manager), "freeze-change",
GUINT_TO_POINTER (level));
}
}
static void
layout_manager_thaw_layout_change (ClutterLayoutManager *manager)
{
gpointer is_frozen;
is_frozen = g_object_get_data (G_OBJECT (manager), "freeze-change");
if (is_frozen == NULL)
g_critical (G_STRLOC ": Mismatched thaw; you have to call "
"clutter_layout_manager_freeze_layout_change() prior to "
"calling clutter_layout_manager_thaw_layout_change()");
else
{
guint level = GPOINTER_TO_UINT (is_frozen);
g_assert (level > 0);
layout-manager: Do not emit layout-changed on thaw When thawing a LayoutManager, do not emit the ::layout-changed signal since it might still be in the middle of a relayout. http://bugzilla.clutter-project.org/show_bug.cgi?id=2255
2010-08-09 06:06:44 -04:00
CLUTTER_NOTE (LAYOUT, "Thawing changes for manager '%s'[%p]",
G_OBJECT_TYPE_NAME (manager),
manager);
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
level -= 1;
if (level == 0)
layout-manager: Do not emit layout-changed on thaw When thawing a LayoutManager, do not emit the ::layout-changed signal since it might still be in the middle of a relayout. http://bugzilla.clutter-project.org/show_bug.cgi?id=2255
2010-08-09 06:06:44 -04:00
g_object_set_data (G_OBJECT (manager), "freeze-change", NULL);
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
else
g_object_set_data (G_OBJECT (manager), "freeze-change",
GUINT_TO_POINTER (level));
}
}
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
static void
layout_manager_real_get_preferred_width (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_height,
gfloat *min_width_p,
gfloat *nat_width_p)
{
LAYOUT_MANAGER_WARN_NOT_IMPLEMENTED (manager, "get_preferred_width");
if (min_width_p)
*min_width_p = 0.0;
if (nat_width_p)
*nat_width_p = 0.0;
}
static void
layout_manager_real_get_preferred_height (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_width,
gfloat *min_height_p,
gfloat *nat_height_p)
{
LAYOUT_MANAGER_WARN_NOT_IMPLEMENTED (manager, "get_preferred_height");
if (min_height_p)
*min_height_p = 0.0;
if (nat_height_p)
*nat_height_p = 0.0;
}
static void
layout_manager_real_allocate (ClutterLayoutManager *manager,
ClutterContainer *container,
const ClutterActorBox *allocation,
ClutterAllocationFlags flags)
{
LAYOUT_MANAGER_WARN_NOT_IMPLEMENTED (manager, "allocate");
}
layout-manager: Implement set_container() Store a back pointer of the layout manager inside the container using the GObject instance data. This introduces a change in the implementation of ClutterLayoutManager, though it's still binary compatible.
2010-06-07 16:34:36 -04:00
static void
layout_manager_real_set_container (ClutterLayoutManager *manager,
ClutterContainer *container)
{
if (container != NULL)
g_object_set_data (G_OBJECT (container), "clutter-layout-manager", manager);
}
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
static ClutterLayoutMeta *
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
layout_manager_real_create_child_meta (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor)
{
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
ClutterLayoutManagerClass *klass;
GType meta_type;
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
meta_type = klass->get_child_meta_type (manager);
/* provide a default implementation to reduce common code */
if (meta_type != G_TYPE_INVALID)
{
g_assert (g_type_is_a (meta_type, CLUTTER_TYPE_LAYOUT_META));
return g_object_new (meta_type,
"manager", manager,
"container", container,
"actor", actor,
NULL);
}
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
return NULL;
}
layout: Add LayoutManager::get_child_meta_type() In order to inspect a LayoutManager using LayoutMeta we need a virtual function that returns the GType of the LayoutMeta used.
2009-11-05 06:57:06 -05:00
static GType
layout_manager_real_get_child_meta_type (ClutterLayoutManager *manager)
{
return G_TYPE_INVALID;
}
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
static ClutterAlpha *
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
layout_manager_real_begin_animation (ClutterLayoutManager *manager,
guint duration,
gulong mode)
{
ClutterTimeline *timeline;
ClutterAlpha *alpha;
alpha = g_object_get_qdata (G_OBJECT (manager), quark_layout_alpha);
if (alpha != NULL)
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
{
layout-manager: Rewind the timeline in begin_animation() If the default implementation begin_animation() is called twice then we should rewind the timeline, as well as updating its duration and the easing mode of the alpha.
2009-12-23 03:39:16 -05:00
clutter_alpha_set_mode (alpha, mode);
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
timeline = clutter_alpha_get_timeline (alpha);
clutter_timeline_set_duration (timeline, duration);
layout-manager: Rewind the timeline in begin_animation() If the default implementation begin_animation() is called twice then we should rewind the timeline, as well as updating its duration and the easing mode of the alpha.
2009-12-23 03:39:16 -05:00
clutter_timeline_rewind (timeline);
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
return alpha;
};
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
timeline = clutter_timeline_new (duration);
layout-manager: Rewind the timeline in begin_animation() If the default implementation begin_animation() is called twice then we should rewind the timeline, as well as updating its duration and the easing mode of the alpha.
2009-12-23 03:39:16 -05:00
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
alpha = clutter_alpha_new_full (timeline, mode);
layout-manager: Rewind the timeline in begin_animation() If the default implementation begin_animation() is called twice then we should rewind the timeline, as well as updating its duration and the easing mode of the alpha.
2009-12-23 03:39:16 -05:00
/* let the alpha take ownership of the timeline */
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
g_object_unref (timeline);
g_signal_connect_swapped (timeline, "completed",
G_CALLBACK (clutter_layout_manager_end_animation),
manager);
g_signal_connect_swapped (timeline, "new-frame",
G_CALLBACK (clutter_layout_manager_layout_changed),
manager);
g_object_set_qdata_full (G_OBJECT (manager),
quark_layout_alpha, alpha,
(GDestroyNotify) g_object_unref);
clutter_timeline_start (timeline);
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
return alpha;
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
}
static gdouble
layout_manager_real_get_animation_progress (ClutterLayoutManager *manager)
{
ClutterAlpha *alpha;
alpha = g_object_get_qdata (G_OBJECT (manager), quark_layout_alpha);
if (alpha == NULL)
return 1.0;
return clutter_alpha_get_alpha (alpha);
}
static void
layout_manager_real_end_animation (ClutterLayoutManager *manager)
{
ClutterTimeline *timeline;
ClutterAlpha *alpha;
alpha = g_object_get_qdata (G_OBJECT (manager), quark_layout_alpha);
if (alpha == NULL)
return;
timeline = clutter_alpha_get_timeline (alpha);
g_assert (timeline != NULL);
if (clutter_timeline_is_playing (timeline))
clutter_timeline_stop (timeline);
g_signal_handlers_disconnect_by_func (timeline,
G_CALLBACK (clutter_layout_manager_end_animation),
manager);
g_signal_handlers_disconnect_by_func (timeline,
G_CALLBACK (clutter_layout_manager_layout_changed),
manager);
g_object_set_qdata (G_OBJECT (manager), quark_layout_alpha, NULL);
clutter_layout_manager_layout_changed (manager);
}
layout-manager: Add compute_expand() vfunc This virtual function will let layout managers with legacy expansion flags be able to influence the lazy computation of the expansion flags on ClutterActor.
2011-12-20 13:38:47 -05:00
static void
layout_manager_real_compute_expand (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *child,
gboolean *x_expand,
gboolean *y_expand)
{
/* be default, we don't interfere with the Actor [xy]-expand */
if (x_expand != NULL)
*x_expand = FALSE;
if (y_expand != NULL)
*y_expand = FALSE;
}
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
static void
clutter_layout_manager_class_init (ClutterLayoutManagerClass *klass)
{
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
quark_layout_meta =
g_quark_from_static_string ("clutter-layout-manager-child-meta");
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
quark_layout_alpha =
g_quark_from_static_string ("clutter-layout-manager-alpha");
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
klass->get_preferred_width = layout_manager_real_get_preferred_width;
klass->get_preferred_height = layout_manager_real_get_preferred_height;
klass->allocate = layout_manager_real_allocate;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
klass->create_child_meta = layout_manager_real_create_child_meta;
layout: Add LayoutManager::get_child_meta_type() In order to inspect a LayoutManager using LayoutMeta we need a virtual function that returns the GType of the LayoutMeta used.
2009-11-05 06:57:06 -05:00
klass->get_child_meta_type = layout_manager_real_get_child_meta_type;
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
klass->begin_animation = layout_manager_real_begin_animation;
klass->get_animation_progress = layout_manager_real_get_animation_progress;
klass->end_animation = layout_manager_real_end_animation;
layout-manager: Implement set_container() Store a back pointer of the layout manager inside the container using the GObject instance data. This introduces a change in the implementation of ClutterLayoutManager, though it's still binary compatible.
2010-06-07 16:34:36 -04:00
klass->set_container = layout_manager_real_set_container;
layout-manager: Add compute_expand() vfunc This virtual function will let layout managers with legacy expansion flags be able to influence the lazy computation of the expansion flags on ClutterActor.
2011-12-20 13:38:47 -05:00
klass->compute_expand = layout_manager_real_compute_expand;
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
/**
* ClutterLayoutManager::layout-changed:
* @manager: the #ClutterLayoutManager that emitted the signal
*
* The ::layout-changed signal is emitted each time a layout manager
* has been changed. Every #ClutterActor using the @manager instance
* as a layout manager should connect a handler to the ::layout-changed
* signal and queue a relayout on themselves:
*
* |[
* static void layout_changed (ClutterLayoutManager *manager,
* ClutterActor *self)
* {
* clutter_actor_queue_relayout (self);
* }
* ...
* self->manager = g_object_ref_sink (manager);
* g_signal_connect (self->manager, "layout-changed",
* G_CALLBACK (layout_changed),
* self);
* ]|
*
* Sub-classes of #ClutterLayoutManager that implement a layout that
* can be controlled or changed using parameters should emit the
* ::layout-changed signal whenever one of the parameters changes,
* by using clutter_layout_manager_layout_changed().
*
* Since: 1.2
*/
manager_signals[LAYOUT_CHANGED] =
g_signal_new (I_("layout-changed"),
G_TYPE_FROM_CLASS (klass),
G_SIGNAL_RUN_LAST,
G_STRUCT_OFFSET (ClutterLayoutManagerClass,
layout_changed),
NULL, NULL,
Hide the marshallers The marshallers we use for the signals are declared in a private header, and it stands to reason that they should also be hidden in the shared object by using the common '_' prefix. We are also using some direct g_cclosure_marshal_* symbol from GLib, instead of consistently use the clutter_marshal_* symbol.
2010-06-11 10:49:46 -04:00
_clutter_marshal_VOID__VOID,
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
G_TYPE_NONE, 0);
[layout] Add initial implementation of LayoutManager The LayoutManager class is an abstract proxy for the size requesition and size allocation process in ClutterActor. A ClutterLayoutManager sub-class must implement get_preferred_width(), get_preferred_height() and allocate(); a ClutterContainer using the LayoutManager API will then proxy the corresponding Actor virtual functions to the LayoutManager instance. This allows having a generic "blank" ClutterActor sub-class, implementing the ClutterContainer interface, which leaves only the layout management implementation to the application developers.
2009-09-01 11:34:28 -04:00
}
static void
clutter_layout_manager_init (ClutterLayoutManager *manager)
{
}
/**
* clutter_layout_manager_get_preferred_width:
* @manager: a #ClutterLayoutManager
* @container: the #ClutterContainer using @manager
* @for_height: the height for which the width should be computed, or -1
* @min_width_p: (out) (allow-none): return location for the minimum width
* of the layout, or %NULL
* @nat_width_p: (out) (allow-none): return location for the natural width
* of the layout, or %NULL
*
* Computes the minimum and natural widths of the @container according
* to @manager.
*
* See also clutter_actor_get_preferred_width()
*
* Since: 1.2
*/
void
clutter_layout_manager_get_preferred_width (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_height,
gfloat *min_width_p,
gfloat *nat_width_p)
{
ClutterLayoutManagerClass *klass;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
klass->get_preferred_width (manager, container, for_height,
min_width_p,
nat_width_p);
}
/**
* clutter_layout_manager_get_preferred_height:
* @manager: a #ClutterLayoutManager
* @container: the #ClutterContainer using @manager
* @for_width: the width for which the height should be computed, or -1
* @min_height_p: (out) (allow-none): return location for the minimum height
* of the layout, or %NULL
* @nat_height_p: (out) (allow-none): return location for the natural height
* of the layout, or %NULL
*
* Computes the minimum and natural heights of the @container according
* to @manager.
*
* See also clutter_actor_get_preferred_height()
*
* Since: 1.2
*/
void
clutter_layout_manager_get_preferred_height (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_width,
gfloat *min_height_p,
gfloat *nat_height_p)
{
ClutterLayoutManagerClass *klass;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
klass->get_preferred_height (manager, container, for_width,
min_height_p,
nat_height_p);
}
/**
* clutter_layout_manager_allocate:
* @manager: a #ClutterLayoutManager
* @container: the #ClutterContainer using @manager
* @allocation: the #ClutterActorBox containing the allocated area
* of @container
* @flags: the allocation flags
*
* Allocates the children of @container given an area
*
* See also clutter_actor_allocate()
*
* Since: 1.2
*/
void
clutter_layout_manager_allocate (ClutterLayoutManager *manager,
ClutterContainer *container,
const ClutterActorBox *allocation,
ClutterAllocationFlags flags)
{
ClutterLayoutManagerClass *klass;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
g_return_if_fail (allocation != NULL);
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
klass->allocate (manager, container, allocation, flags);
}
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
/**
* clutter_layout_manager_layout_changed:
* @manager: a #ClutterLayoutManager
*
* Emits the #ClutterLayoutManager::layout-changed signal on @manager
*
* This function should only be called by implementations of the
* #ClutterLayoutManager class
*
* Since: 1.2
*/
void
clutter_layout_manager_layout_changed (ClutterLayoutManager *manager)
{
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
gpointer is_frozen;
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
is_frozen = g_object_get_data (G_OBJECT (manager), "freeze-change");
if (is_frozen == NULL)
g_signal_emit (manager, manager_signals[LAYOUT_CHANGED], 0);
layout-manager: Do not emit layout-changed on thaw When thawing a LayoutManager, do not emit the ::layout-changed signal since it might still be in the middle of a relayout. http://bugzilla.clutter-project.org/show_bug.cgi?id=2255
2010-08-09 06:06:44 -04:00
else
CLUTTER_NOTE (LAYOUT, "Layout manager '%s'[%p] has been frozen",
G_OBJECT_TYPE_NAME (manager),
manager);
[layout] Add LayoutManager::layout-changed signal If a sub-class of LayoutManager wishes to implement a parametrized layout policy it also needs a way to notify the container using the layout manager that the layout has changed. We cannot do it directly and automatically from the LayoutManager because a) it has no back link to the actor that it is using it and b) it can be attached to multiple actors. This is a job for <cue raising dramatic music> signals! By adding ClutterLayoutManager::layout-changed (and its relative emitted function) we can notify actors using the layout manager that the layout parameters have been changed, and thus they should queue a relayout.
2009-09-14 06:04:11 -04:00
}
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
[layout] Allow taking a back pointer to the Container The LayoutManager implementation might opt to take a back pointer to the Container that is using the layout instance; this allows direct access to the container itself from within the implementation.
2009-09-16 09:58:30 -04:00
/**
* clutter_layout_manager_set_container:
* @manager: a #ClutterLayoutManager
* @container: (allow-none): a #ClutterContainer using @manager
*
* If the #ClutterLayoutManager sub-class allows it, allow
* adding a weak reference of the @container using @manager
* from within the layout manager
*
* The layout manager should not increase the reference
* count of the @container
*
* Since: 1.2
*/
void
clutter_layout_manager_set_container (ClutterLayoutManager *manager,
ClutterContainer *container)
{
ClutterLayoutManagerClass *klass;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (container == NULL || CLUTTER_IS_CONTAINER (container));
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
if (klass->set_container)
klass->set_container (manager, container);
}
layout-manager: Implement set_container() Store a back pointer of the layout manager inside the container using the GObject instance data. This introduces a change in the implementation of ClutterLayoutManager, though it's still binary compatible.
2010-06-07 16:34:36 -04:00
GType
_clutter_layout_manager_get_child_meta_type (ClutterLayoutManager *manager)
{
return CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager)->get_child_meta_type (manager);
}
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
static inline ClutterLayoutMeta *
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
create_child_meta (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor)
{
ClutterLayoutManagerClass *klass;
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
ClutterLayoutMeta *meta = NULL;
layout_manager_freeze_layout_change (manager);
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
if (klass->get_child_meta_type (manager) != G_TYPE_INVALID)
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
meta = klass->create_child_meta (manager, container, actor);
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
layout-manager: Freeze ::layout-changed when creating LayoutMeta LayoutMeta instances are created lazily. If an actor is added to a container with a layout manager then the first time the layout manager might be creating the LayoutMeta instance could be during the allocation cycle caused by calling clutter_actor_show(). When a LayoutMeta is instantiated for the first time, a list of properties can be set - and this might lead to the emission of the ::layout-changed signal. The signal is, most typically, going to cause a relayout to be queued, and a warning will be printed on the terminal. We should freeze the emission of the ::layout-changed signal during the creation of the LayoutMeta instances, and thaw it after that.
2010-08-05 13:10:22 -04:00
layout_manager_thaw_layout_change (manager);
return meta;
layout: Do not create a LayoutMeta on remove When calling remove_child_meta() we check if there is a LayoutMeta already attached to the Actor, and if that LayoutMeta matches the (manager, container, actor) tuple. If the LayoutMeta does not match, though, we create a new LayoutMeta instance -- in order to remove it right afterwards. Instead of doing this, we can simply check for a matching LayoutMeta and if present, remove it. In case of an existing, non-matching LayoutMeta, we're left with a dangling instance, but it does not matter: the removal happens in the unparenting phase of a ClutterContainer, so either the Actor will be destroyed and thus the LayoutMeta will be disposed along with it; or it will be parented to another container, and thus the LayoutMeta will be replaced.
2009-10-26 12:02:06 -04:00
}
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
static inline ClutterLayoutMeta *
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
get_child_meta (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor)
{
[layout] Replace stale LayoutMeta If a LayoutMeta references a different container and/or layout manager then we should simply replace it and discard the previous one.
2009-09-16 10:47:26 -04:00
ClutterLayoutMeta *layout = NULL;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
layout = g_object_get_qdata (G_OBJECT (actor), quark_layout_meta);
if (layout != NULL)
{
ClutterChildMeta *child = CLUTTER_CHILD_META (layout);
if (layout->manager == manager &&
child->container == container &&
child->actor == actor)
return layout;
[layout] Replace stale LayoutMeta If a LayoutMeta references a different container and/or layout manager then we should simply replace it and discard the previous one.
2009-09-16 10:47:26 -04:00
/* if the LayoutMeta referenced is not attached to the
* layout manager then we simply ask the layout manager
* to replace it with the right one
*/
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
}
[layout] Replace stale LayoutMeta If a LayoutMeta references a different container and/or layout manager then we should simply replace it and discard the previous one.
2009-09-16 10:47:26 -04:00
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
layout = create_child_meta (manager, container, actor);
if (layout != NULL)
{
g_assert (CLUTTER_IS_LAYOUT_META (layout));
g_object_set_qdata_full (G_OBJECT (actor), quark_layout_meta,
layout,
(GDestroyNotify) g_object_unref);
[layout] Replace stale LayoutMeta If a LayoutMeta references a different container and/or layout manager then we should simply replace it and discard the previous one.
2009-09-16 10:47:26 -04:00
return layout;
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
}
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
return NULL;
}
/**
* clutter_layout_manager_get_child_meta:
* @manager: a #ClutterLayoutManager
* @container: a #ClutterContainer using @manager
* @actor: a #ClutterActor child of @container
*
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
* Retrieves the #ClutterLayoutMeta that the layout @manager associated
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
* to the @actor child of @container, eventually by creating one if the
* #ClutterLayoutManager supports layout properties
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
*
introspection: Add annotations Reduce the amount of warnings coming from g-ir-scanner.
2010-09-03 07:14:50 -04:00
* Return value: (transfer none): a #ClutterLayoutMeta, or %NULL if the
* #ClutterLayoutManager does not have layout properties. The returned
* layout meta instance is owned by the #ClutterLayoutManager and it
* should not be unreferenced
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
*
* Since: 1.0
*/
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
ClutterLayoutMeta *
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
clutter_layout_manager_get_child_meta (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor)
{
g_return_val_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager), NULL);
g_return_val_if_fail (CLUTTER_IS_CONTAINER (container), NULL);
g_return_val_if_fail (CLUTTER_IS_ACTOR (actor), NULL);
return get_child_meta (manager, container, actor);
}
static inline gboolean
layout_set_property_internal (ClutterLayoutManager *manager,
GObject *gobject,
GParamSpec *pspec,
const GValue *value)
{
if (pspec->flags & G_PARAM_CONSTRUCT_ONLY)
{
g_warning ("%s: Child property '%s' of the layout manager of "
"type '%s' is constructor-only",
G_STRLOC, pspec->name, G_OBJECT_TYPE_NAME (manager));
return FALSE;
}
if (!(pspec->flags & G_PARAM_WRITABLE))
{
g_warning ("%s: Child property '%s' of the layout manager of "
"type '%s' is not writable",
G_STRLOC, pspec->name, G_OBJECT_TYPE_NAME (manager));
return FALSE;
}
g_object_set_property (gobject, pspec->name, value);
return TRUE;
}
static inline gboolean
layout_get_property_internal (ClutterLayoutManager *manager,
GObject *gobject,
GParamSpec *pspec,
GValue *value)
{
if (!(pspec->flags & G_PARAM_READABLE))
{
g_warning ("%s: Child property '%s' of the layout manager of "
"type '%s' is not readable",
G_STRLOC, pspec->name, G_OBJECT_TYPE_NAME (manager));
return FALSE;
}
g_object_get_property (gobject, pspec->name, value);
return TRUE;
}
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
/**
* clutter_layout_manager_child_set:
* @manager: a #ClutterLayoutManager
* @container: a #ClutterContainer using @manager
* @actor: a #ClutterActor child of @container
* @first_property: the first property name
docs: Fixes for building the API reference
2011-07-26 08:43:37 -04:00
* @...: a list of property name and value pairs
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
*
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
* Sets a list of properties and their values on the #ClutterLayoutMeta
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
* associated by @manager to a child of @container
*
* Languages bindings should use clutter_layout_manager_child_set_property()
* instead
*
* Since: 1.2
*/
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
void
clutter_layout_manager_child_set (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *first_property,
...)
{
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
ClutterLayoutMeta *meta;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
GObjectClass *klass;
const gchar *pname;
va_list var_args;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
g_return_if_fail (CLUTTER_IS_ACTOR (actor));
g_return_if_fail (first_property != NULL);
meta = get_child_meta (manager, container, actor);
if (meta == NULL)
{
g_warning ("Layout managers of type '%s' do not support "
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
"layout metadata",
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
g_type_name (G_OBJECT_TYPE (manager)));
return;
}
klass = G_OBJECT_GET_CLASS (meta);
va_start (var_args, first_property);
pname = first_property;
while (pname)
{
GValue value = { 0, };
GParamSpec *pspec;
gchar *error;
gboolean res;
pspec = g_object_class_find_property (klass, pname);
if (pspec == NULL)
{
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
g_warning ("%s: Layout managers of type '%s' have no layout "
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
"property named '%s'",
G_STRLOC, G_OBJECT_TYPE_NAME (manager), pname);
break;
}
Conditionally use G_VALUE_COLLECT_INIT() macro GLib 2.24 (but starting from the 2.23.2 unstable release) added a new macro for collecting GValues from a va_list. The newly added G_VALUE_COLLECT_INIT() macro should be used in place of initializing the GValue and calling G_VALUE_COLLECT(), and improves the collection performances by avoiding multiple checks, free and initialization calls.
2010-02-25 05:22:36 -05:00
G_VALUE_COLLECT_INIT (&value, G_PARAM_SPEC_VALUE_TYPE (pspec),
var_args, 0,
&error);
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
if (error)
{
g_warning ("%s: %s", G_STRLOC, error);
g_free (error);
break;
}
res = layout_set_property_internal (manager, G_OBJECT (meta),
pspec,
&value);
g_value_unset (&value);
if (!res)
break;
pname = va_arg (var_args, gchar*);
}
va_end (var_args);
}
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
/**
* clutter_layout_manager_child_set_property:
* @manager: a #ClutterLayoutManager
* @container: a #ClutterContainer using @manager
* @actor: a #ClutterActor child of @container
* @property_name: the name of the property to set
* @value: a #GValue with the value of the property to set
*
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
* Sets a property on the #ClutterLayoutMeta created by @manager and
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
* attached to a child of @container
*
* Since: 1.2
*/
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
void
clutter_layout_manager_child_set_property (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *property_name,
const GValue *value)
{
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
ClutterLayoutMeta *meta;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
GObjectClass *klass;
GParamSpec *pspec;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
g_return_if_fail (CLUTTER_IS_ACTOR (actor));
g_return_if_fail (property_name != NULL);
g_return_if_fail (value != NULL);
meta = get_child_meta (manager, container, actor);
if (meta == NULL)
{
g_warning ("Layout managers of type '%s' do not support "
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
"layout metadata",
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
g_type_name (G_OBJECT_TYPE (manager)));
return;
}
klass = G_OBJECT_GET_CLASS (meta);
pspec = g_object_class_find_property (klass, property_name);
if (pspec == NULL)
{
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
g_warning ("%s: Layout managers of type '%s' have no layout "
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
"property named '%s'",
G_STRLOC, G_OBJECT_TYPE_NAME (manager), property_name);
return;
}
layout_set_property_internal (manager, G_OBJECT (meta), pspec, value);
}
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
/**
* clutter_layout_manager_child_get:
* @manager: a #ClutterLayoutManager
* @container: a #ClutterContainer using @manager
* @actor: a #ClutterActor child of @container
* @first_property: the name of the first property
docs: Fixes for building the API reference
2011-07-26 08:43:37 -04:00
* @...: a list of property name and return location for the value pairs
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
*
* Retrieves the values for a list of properties out of the
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
* #ClutterLayoutMeta created by @manager and attached to the
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
* child of a @container
*
* Since: 1.2
*/
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
void
clutter_layout_manager_child_get (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *first_property,
...)
{
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
ClutterLayoutMeta *meta;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
GObjectClass *klass;
const gchar *pname;
va_list var_args;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
g_return_if_fail (CLUTTER_IS_ACTOR (actor));
g_return_if_fail (first_property != NULL);
meta = get_child_meta (manager, container, actor);
if (meta == NULL)
{
g_warning ("Layout managers of type '%s' do not support "
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
"layout metadata",
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
g_type_name (G_OBJECT_TYPE (manager)));
return;
}
klass = G_OBJECT_GET_CLASS (meta);
va_start (var_args, first_property);
pname = first_property;
while (pname)
{
GValue value = { 0, };
GParamSpec *pspec;
gchar *error;
gboolean res;
pspec = g_object_class_find_property (klass, pname);
if (pspec == NULL)
{
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
g_warning ("%s: Layout managers of type '%s' have no layout "
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
"property named '%s'",
G_STRLOC, G_OBJECT_TYPE_NAME (manager), pname);
break;
}
g_value_init (&value, G_PARAM_SPEC_VALUE_TYPE (pspec));
res = layout_get_property_internal (manager, G_OBJECT (meta),
pspec,
&value);
if (!res)
{
g_value_unset (&value);
break;
}
G_VALUE_LCOPY (&value, var_args, 0, &error);
if (error)
{
g_warning ("%s: %s", G_STRLOC, error);
g_free (error);
g_value_unset (&value);
break;
}
g_value_unset (&value);
pname = va_arg (var_args, gchar*);
}
va_end (var_args);
}
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
/**
* clutter_layout_manager_child_get_property:
* @manager: a #ClutterLayoutManager
* @container: a #ClutterContainer using @manager
* @actor: a #ClutterActor child of @container
* @property_name: the name of the property to get
* @value: a #GValue with the value of the property to get
*
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
* Gets a property on the #ClutterLayoutMeta created by @manager and
[layout, docs] Add layout managers sections Add LayoutManager and its subclasses, and the Box actor to the gtk-doc machinery needed to generate the API reference.
2009-09-15 11:24:47 -04:00
* attached to a child of @container
*
* The #GValue must already be initialized to the type of the property
* and has to be unset with g_value_unset() after extracting the real
* value out of it
*
* Since: 1.2
*/
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
void
clutter_layout_manager_child_get_property (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *property_name,
GValue *value)
{
[layout] Add LayoutMeta Instead of overloading ClutterChildMeta with both container and layout metadata and delegate to every LayoutManager implementation to keep a backpointer to the layout manager instance, we can simply subclass ChildMeta into LayoutMeta and presto! everything works out pretty well for everyone.
2009-09-15 12:37:11 -04:00
ClutterLayoutMeta *meta;
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
GObjectClass *klass;
GParamSpec *pspec;
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
g_return_if_fail (CLUTTER_IS_CONTAINER (container));
g_return_if_fail (CLUTTER_IS_ACTOR (actor));
g_return_if_fail (property_name != NULL);
g_return_if_fail (value != NULL);
meta = get_child_meta (manager, container, actor);
if (meta == NULL)
{
g_warning ("Layout managers of type %s do not support "
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
"layout metadata",
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
g_type_name (G_OBJECT_TYPE (manager)));
return;
}
klass = G_OBJECT_GET_CLASS (meta);
pspec = g_object_class_find_property (klass, property_name);
if (pspec == NULL)
{
layout-manager: Create LayoutMeta on demand The ClutterLayoutMeta instances should be created on demand, whenever the layout manager needs them - if the layout manager supports layout properties. This removes the requirement to call add_child_meta() and remove_child_meta() on add and remove respectively; it also simplifies the implementation of LayoutManager sub-classes since we can add fallback code in the base abstract class. Eventually, this will also lead to an easier to implement ClutterScript parser for layout properties. With the new scheme, the ClutterLayoutMeta instance is created whenever the layout manager tries to access it; if there isn't an instance already attached to the container's child, one is created -- assuming that the LayoutManager sub-class has overridden the get_child_meta_type() virtual function and it's returning a valid GType. We can also provide a default implementation for create_child_meta(), by getting the GType and instantiating a ClutterLayoutMeta with all the fields already set. If the layout manager requires more work then it can obviously override the default implementation (and even chain up to it). The ClutterBox actor has been updated, as well as the ClutterBoxLayout layout manager, to take advantage of the changes of LayoutManager.
2009-11-30 14:03:11 -05:00
g_warning ("%s: Layout managers of type '%s' have no layout "
[layout] Bind ChildMeta to LayoutManager The ChildMeta object is a storage for child-container properties, that is properties that exist only when an actor is inside a specific container. The LayoutManager delegate class should also have layout-specific properties -- so, for this job, we can "recycle" ChildMeta as the storage.
2009-09-14 16:48:06 -04:00
"property named '%s'",
G_STRLOC, G_OBJECT_TYPE_NAME (manager), property_name);
return;
}
layout_get_property_internal (manager, G_OBJECT (meta), pspec, value);
}
layout: Add layout properties introspection In order to know if a layout property exists and retrieve its description in form of a GParamSpec, we need a wrapper API inside ClutterLayoutManager. This allows introspecting a LayoutManager sub-class and eventually serialize and deserialize it.
2009-11-05 07:24:37 -05:00
/**
* clutter_layout_manager_find_child_property:
* @manager: a #ClutterLayoutManager
* @name: the name of the property
*
* Retrieves the #GParamSpec for the layout property @name inside
* the #ClutterLayoutMeta sub-class used by @manager
*
* Return value: (transfer none): a #GParamSpec describing the property,
* or %NULL if no property with that name exists. The returned
* #GParamSpec is owned by the layout manager and should not be
* modified or freed
*
* Since: 1.2
*/
GParamSpec *
clutter_layout_manager_find_child_property (ClutterLayoutManager *manager,
const gchar *name)
{
ClutterLayoutManagerClass *klass;
GObjectClass *meta_klass;
GParamSpec *pspec;
GType meta_type;
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
meta_type = klass->get_child_meta_type (manager);
if (meta_type == G_TYPE_INVALID)
return NULL;
meta_klass = g_type_class_ref (meta_type);
pspec = g_object_class_find_property (meta_klass, name);
g_type_class_unref (meta_klass);
return pspec;
}
/**
* clutter_layout_manager_list_child_properties:
* @manager: a #ClutterLayoutManager
* @n_pspecs: (out): return location for the number of returned
* #GParamSpec<!-- -->s
*
* Retrieves all the #GParamSpec<!-- -->s for the layout properties
* stored inside the #ClutterLayoutMeta sub-class used by @manager
*
Further annotation fixes
2010-09-08 11:41:47 -04:00
* Return value: (transfer full) (array length=n_pspecs): the newly-allocated,
* %NULL-terminated array of #GParamSpec<!-- -->s. Use g_free() to free the
* resources allocated for the array
layout: Add layout properties introspection In order to know if a layout property exists and retrieve its description in form of a GParamSpec, we need a wrapper API inside ClutterLayoutManager. This allows introspecting a LayoutManager sub-class and eventually serialize and deserialize it.
2009-11-05 07:24:37 -05:00
*
* Since: 1.2
*/
GParamSpec **
clutter_layout_manager_list_child_properties (ClutterLayoutManager *manager,
guint *n_pspecs)
{
ClutterLayoutManagerClass *klass;
GObjectClass *meta_klass;
GParamSpec **pspecs;
GType meta_type;
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
meta_type = klass->get_child_meta_type (manager);
if (meta_type == G_TYPE_INVALID)
return NULL;
meta_klass = g_type_class_ref (meta_type);
pspecs = g_object_class_list_properties (meta_klass, n_pspecs);
g_type_class_unref (meta_klass);
return pspecs;
}
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
/**
* clutter_layout_manager_begin_animation:
* @manager: a #ClutterLayoutManager
* @duration: the duration of the animation, in milliseconds
* @mode: the easing mode of the animation
*
* Begins an animation of @duration milliseconds, using the provided
* easing @mode
*
* The easing mode can be specified either as a #ClutterAnimationMode
* or as a logical id returned by clutter_alpha_register_func()
*
* The result of this function depends on the @manager implementation
*
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
* Return value: (transfer none): The #ClutterAlpha created by the
* layout manager; the returned instance is owned by the layout
* manager and should not be unreferenced
*
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
* Since: 1.2
*/
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
ClutterAlpha *
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
clutter_layout_manager_begin_animation (ClutterLayoutManager *manager,
guint duration,
gulong mode)
{
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
ClutterLayoutManagerClass *klass;
g_return_val_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager), NULL);
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
layout: Let begin_animation() return the Alpha When beginning a new animation for a LayoutManager, the implementation should return the ClutterAlpha used. This allows controlling the timeline and/or modifying the animation parameters on the fly.
2009-12-12 20:23:54 -05:00
return klass->begin_animation (manager, duration, mode);
layout: Add animation support to LayoutManager In order to animate a fluid layout we cannot use the common animation code paths as they will override the size request and allocation paths that are handled by the layout manager itself. One way to introduce animations in the allocation sequence is to use a Timeline and an Alpha to compute a progress value and then use that value to interpolate an ActorBox between the initial and final states of the animation - with the initial state being the last allocation of the child prior to the animation start, and the final state the allocation of the child at the end; for every frame of the Timeline we then queue a relayout on the layout manager's container, which will result in an animation. ClutterLayoutManager is the most likely place to add a generic API for beginning and ending an animation, as well as the place to provide a default code path to create the ancillary Timeline and Alpha instances needed to drive the animation. A LayoutManager sub-class will need to: • call clutter_layout_manager_begin_animation() whenever it should animate between two states, for instance: whenever a layout property changes value; • eventually override begin_animation() and end_animation() in case further state needs to be set up, and then chain up to the default implementation provided by LayoutManager; • if a completely different implementation is required, the layout manager sub-class should override begin_animation(), end_animation() and get_animation_progress(). Inside the allocate() implementation the sub-class should also interpolate between the last known allocation of a child and the newly computed allocation.
2009-12-11 19:02:43 -05:00
}
/**
* clutter_layout_manager_end_animation:
* @manager: a #ClutterLayoutManager
*
* Ends an animation started by clutter_layout_manager_begin_animation()
*
* The result of this call depends on the @manager implementation
*
* Since: 1.2
*/
void
clutter_layout_manager_end_animation (ClutterLayoutManager *manager)
{
g_return_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager));
CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager)->end_animation (manager);
}
/**
* clutter_layout_manager_get_animation_progress:
* @manager: a #ClutterLayoutManager
*
* Retrieves the progress of the animation, if one has been started by
* clutter_layout_manager_begin_animation()
*
* The returned value has the same semantics of the #ClutterAlpha:alpha
* value
*
* Return value: the progress of the animation
*
* Since: 1.2
*/
gdouble
clutter_layout_manager_get_animation_progress (ClutterLayoutManager *manager)
{
ClutterLayoutManagerClass *klass;
g_return_val_if_fail (CLUTTER_IS_LAYOUT_MANAGER (manager), 1.0);
klass = CLUTTER_LAYOUT_MANAGER_GET_CLASS (manager);
return klass->get_animation_progress (manager);
}
Reference in New Issue Copy Permalink