Commit Graph

30 Commits

Author SHA1 Message Date
Emmanuele Bassi
683642ba54 docs: Fixes for the API reference build 2011-11-03 16:05:36 +00:00
Emmanuele Bassi
8083dd5178 docs: Improve documentation of LayoutManager
Especially with regards to layout properties and their usage inside a
ClutterScript UI definition.
2011-10-17 11:48:47 +01:00
Emmanuele Bassi
78049c38bf docs: Fixes for building the API reference 2011-07-26 13:44:12 +01:00
Emmanuele Bassi
8429aa8d75 Remove unnecessary GLib version checks
We now depend on a newer version of GLib than those checks tested for.
2010-10-18 11:26:45 +01:00
Emmanuele Bassi
8a5686d835 Further annotation fixes 2010-09-08 16:41:47 +01:00
Emmanuele Bassi
3e74f42f07 introspection: Add annotations
Reduce the amount of warnings coming from g-ir-scanner.
2010-09-03 12:14:50 +01:00
Emmanuele Bassi
28378f1bb4 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 11:06:44 +01:00
Emmanuele Bassi
069266f3ed 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 18:10:22 +01:00
Emmanuele Bassi
b2c905ff50 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 16:09:36 +01:00
Emmanuele Bassi
ab76584965 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 22:40:34 +01:00
Emmanuele Bassi
26e22b2ede 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 10:22:36 +00:00
Emmanuele Bassi
934eee17ae 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 10:37:10 +00:00
Emmanuele Bassi
713c295241 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 10:37:09 +00:00
Emmanuele Bassi
4a21425f48 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-13 01:23:54 +00:00
Emmanuele Bassi
f94a903d9e 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-13 01:13:42 +00:00
Emmanuele Bassi
fc7bbf1abf docs: Fix docbook syntax
The <variablename> tag is really called <varname> in DocBook.
2009-12-02 14:15:19 +00:00
Emmanuele Bassi
15a04a1dd3 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 19:11:00 +00:00
Emmanuele Bassi
c3368c0d15 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 12:26:57 +00:00
Emmanuele Bassi
e6dff59b27 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 12:09:44 +00:00
Emmanuele Bassi
5a14db5089 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 16:02:06 +00:00
Emmanuele Bassi
8ce8b91383 docs: Reword a link 2009-10-19 11:44:29 +01:00
Emmanuele Bassi
cd3c85f7ba 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 11:00:23 +01:00
Emmanuele Bassi
22bb243ec2 [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-10-14 11:31:29 +01:00
Emmanuele Bassi
9117ee2056 [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-10-14 11:31:29 +01:00
Emmanuele Bassi
a2086f1178 [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-10-14 11:31:26 +01:00
Emmanuele Bassi
899db6f226 [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-10-14 11:30:43 +01:00
Emmanuele Bassi
7051fe275d [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-10-14 11:27:29 +01:00
Emmanuele Bassi
d096a3c791 [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-10-14 11:27:29 +01:00
Emmanuele Bassi
141a155690 [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-10-14 11:27:18 +01:00
Emmanuele Bassi
d6183e95e5 [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-10-14 11:27:18 +01:00