brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
77db999339
mutter/clutter/clutter-layout-manager.h

228 lines
12 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
#if !defined(__CLUTTER_H_INSIDE__) && !defined(CLUTTER_COMPILATION)
#error "Only <clutter/clutter.h> can be included directly."
#endif
#ifndef __CLUTTER_LAYOUT_MANAGER_H__
#define __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/clutter-types.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
G_BEGIN_DECLS
#define CLUTTER_TYPE_LAYOUT_MANAGER (clutter_layout_manager_get_type ())
#define CLUTTER_LAYOUT_MANAGER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), CLUTTER_TYPE_LAYOUT_MANAGER, ClutterLayoutManager))
#define CLUTTER_IS_LAYOUT_MANAGER(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), CLUTTER_TYPE_LAYOUT_MANAGER))
#define CLUTTER_LAYOUT_MANAGER_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), CLUTTER_TYPE_LAYOUT_MANAGER, ClutterLayoutManagerClass))
#define CLUTTER_IS_LAYOUT_MANAGER_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), CLUTTER_TYPE_LAYOUT_MANAGER))
#define CLUTTER_LAYOUT_MANAGER_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), CLUTTER_TYPE_LAYOUT_MANAGER, ClutterLayoutManagerClass))
typedef struct _ClutterLayoutManagerClass ClutterLayoutManagerClass;
/**
* ClutterLayoutManager:
*
* The #ClutterLayoutManager structure contains only private data
* and should be accessed using the provided API
*
* Since: 1.2
*/
struct _ClutterLayoutManager
{
[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
/*< private >*/
[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
GInitiallyUnowned parent_instance;
[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
Use the new macros for adding private data
2013-07-03 09:14:01 -04:00
gpointer CLUTTER_PRIVATE_FIELD (dummy);
[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
};
/**
* ClutterLayoutManagerClass:
[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
* @get_preferred_width: virtual function; override to provide a preferred
* width for the layout manager. See also the get_preferred_width()
* virtual function in #ClutterActor
* @get_preferred_height: virtual function; override to provide a preferred
* height for the layout manager. See also the get_preferred_height()
* virtual function in #ClutterActor
* @allocate: virtual function; override to allocate the children of the
* layout manager. See also the allocate() virtual function in
* #ClutterActor
[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
* @set_container: virtual function; override to set a back pointer
* on the #ClutterContainer using the layout manager. The implementation
* should not take a reference on the container, but just take a weak
* reference, to avoid potential leaks due to reference cycles
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
* @get_child_meta_type: virtual function; override to return the #GType
* of the #ClutterLayoutMeta sub-class used by the #ClutterLayoutManager
[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
* @create_child_meta: virtual function; override to create a
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
* #ClutterLayoutMeta instance associated to a #ClutterContainer and a
[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 #ClutterActor, used to maintain layout manager specific properties
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
* @begin_animation: virtual function; override to control the animation
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
* of a #ClutterLayoutManager with the given duration and easing mode.
* This virtual function is deprecated, and it should not be overridden
* in newly written code.
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
* @end_animation: virtual function; override to end an animation started
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
* by clutter_layout_manager_begin_animation(). This virtual function is
* deprecated, and it should not be overriden in newly written code.
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
* @get_animation_progress: virtual function; override to control the
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
* progress of the animation of a #ClutterLayoutManager. This virtual
* function is deprecated, and it should not be overridden in newly written
* code.
[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_changed: class handler for the #ClutterLayoutManager::layout-changed
* signal
[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
*
* The #ClutterLayoutManagerClass structure contains only private
* data and should be accessed using the provided API
*
* Since: 1.2
*/
struct _ClutterLayoutManagerClass
{
[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
/*< private >*/
[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
GInitiallyUnownedClass parent_class;
[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 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
/*< public >*/
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
void (* get_preferred_width) (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_height,
Reduce the amount of g-ir-scanner warnings As much as we can; the remaining warnings are mostly valid things that the introspection scanner still flags as potential issues.
2010-12-09 07:36:50 -05:00
gfloat *min_width_p,
gfloat *nat_width_p);
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
void (* get_preferred_height) (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_width,
Reduce the amount of g-ir-scanner warnings As much as we can; the remaining warnings are mostly valid things that the introspection scanner still flags as potential issues.
2010-12-09 07:36:50 -05:00
gfloat *min_height_p,
gfloat *nat_height_p);
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
void (* allocate) (ClutterLayoutManager *manager,
ClutterContainer *container,
const ClutterActorBox *allocation,
ClutterAllocationFlags flags);
void (* set_container) (ClutterLayoutManager *manager,
ClutterContainer *container);
GType (* get_child_meta_type) (ClutterLayoutManager *manager);
ClutterLayoutMeta *(* create_child_meta) (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor);
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
/* deprecated */
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 * (* begin_animation) (ClutterLayoutManager *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
guint duration,
gulong mode);
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
/* deprecated */
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
gdouble (* get_animation_progress) (ClutterLayoutManager *manager);
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
/* deprecated */
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
void (* end_animation) (ClutterLayoutManager *manager);
void (* layout_changed) (ClutterLayoutManager *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
/*< private >*/
/* padding for future expansion */
[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
void (* _clutter_padding_1) (void);
void (* _clutter_padding_2) (void);
void (* _clutter_padding_3) (void);
void (* _clutter_padding_4) (void);
void (* _clutter_padding_5) (void);
void (* _clutter_padding_6) (void);
void (* _clutter_padding_7) (void);
actor: Remove automagic "expand" flag I don't feel comfortable with this feature, and its implementation still has too many rough edges. We can safely punt it for now, and introduce it at a later point, as it doesn't block existing features or API.
2011-12-21 12:07:25 -05:00
void (* _clutter_padding_8) (void);
[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
};
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
[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
GType clutter_layout_manager_get_type (void) G_GNUC_CONST;
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_get_preferred_width (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_height,
gfloat *min_width_p,
gfloat *nat_width_p);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_get_preferred_height (ClutterLayoutManager *manager,
ClutterContainer *container,
gfloat for_width,
gfloat *min_height_p,
gfloat *nat_height_p);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_allocate (ClutterLayoutManager *manager,
ClutterContainer *container,
const ClutterActorBox *allocation,
ClutterAllocationFlags flags);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_set_container (ClutterLayoutManager *manager,
ClutterContainer *container);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_layout_changed (ClutterLayoutManager *manager);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
GParamSpec * clutter_layout_manager_find_child_property (ClutterLayoutManager *manager,
const gchar *name);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
GParamSpec ** clutter_layout_manager_list_child_properties (ClutterLayoutManager *manager,
guint *n_pspecs);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
ClutterLayoutMeta *clutter_layout_manager_get_child_meta (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_child_set (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *first_property,
...) G_GNUC_NULL_TERMINATED;
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_child_get (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *first_property,
...) G_GNUC_NULL_TERMINATED;
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_child_set_property (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *property_name,
const GValue *value);
Annotate all public symbols We are going to switch to compiler annotations to determine the visibility of the symbols.
2014-03-17 14:19:52 -04:00
CLUTTER_AVAILABLE_IN_1_2
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
void clutter_layout_manager_child_get_property (ClutterLayoutManager *manager,
ClutterContainer *container,
ClutterActor *actor,
const gchar *property_name,
GValue *value);
[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-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
CLUTTER_DEPRECATED_IN_1_12
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 * clutter_layout_manager_begin_animation (ClutterLayoutManager *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
guint duration,
gulong mode);
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
CLUTTER_DEPRECATED_IN_1_12
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
void clutter_layout_manager_end_animation (ClutterLayoutManager *manager);
layout-manager: Deprecate the layout animation This semi-aborted API was broken for various reasons: - it strongly depended on ClutterAlpha, a class we're trying to deprecate; - it requires a lot of boilerplate and copy-and-paste code; - it requires a full relayout of the actor tree for something that ought to be automatically handled by ClutterActor. Now that clutter_actor_allocate() handles transitions using the easing state of the actor, we can deprecate the LayoutManager API for the 1.x series, and remove it for the 2.x series.
2012-04-20 13:14:42 -04:00
CLUTTER_DEPRECATED_IN_1_12
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
gdouble clutter_layout_manager_get_animation_progress (ClutterLayoutManager *manager);
[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
G_END_DECLS
#endif /* __CLUTTER_LAYOUT_MANAGER_H__ */
Reference in New Issue Copy Permalink