Input Methods require to be able to set a "pre-edit string", that is
a string that it's just displayed into the Text actor without being
committed to the actor's buffer. The string might require custom Pango
attributes, and an update of the cursor position.
Out of tree builds were broken in commit 46b736f42e since we didn't
explicitly use $(srcdir) to find the input files for glib-mkenums and
glib-genmarshal.
Casting a float to int to truncate it before assigning the value
to a float again is wrong. We should use ceilf() instead which
does what we want to achieve (rounding up the size to avoid
sub-pixel positioning of children).
* Use g_list_foreach() instead of iterating over the list inside
the destruction sequence, since we are causing the widgets to be
implicitly removed from the list via the destroy() call.
* Use g_signal_connect_swapped() and spare us from a callback.
FlowLayout should compute the correct height for the assigned width when
in horizontal flow, and the correct width for the assigned height when
in vertical flow. This means pre-computing the number of lines inside
the get_preferred_width() and get_preferred_height(). We can then cache
the computed column width and row height, cache them inside the layout
and then use them when allocating the children.
When changing the orientation of a FlowLayout, the associated
container should also change its request mode. A horizontally
flowing layout has a height depending on the width, since it
will reflow vertically; similarly, a vertically reflowing layout
will have a width depending on the height.
The :wrap property is not implemented, and mostly useless: the
FlowLayout is a reflowing grid. This means that if it receives
less than the preferred width or height in the flow direction
then it should always reflow.
Use the column and row size to align each child; with :homogeneous
set to TRUE, or with children with the same size, the FlowLayout
will behave like a reflowing grid.
FlowLayout is a layout manager that arranges its children in a
reflowing line; the orientation controls the major axis for the
layout: horizontal, for reflow on the Y axis, and vertical, for
reflow on the X axis.
There are three potential variants to add a child inside a Box
with a BinLayout:
- clutter_box_pack(), a variadic argument function which
allows passing arbitrary LayoutMeta properties and values;
- clutter_bin_layout_add(), which uses the backpointer to
the container from the LayoutManager and sets the layout
properties directly without GValue (de)marshalling
- clutter_container_add_actor() and
clutter_bin_layout_set_alignment(), similar to the
clutter_bin_layout_add() function above, but split in two
The test-box interactive test should exercise all three variants.
The BinLayout should store a pointer to the Container that it is
using it as the layout manager.
This allows us to fix the API and drop the additional Container
arguments from set_alignment() and get_alignment().
This also allows us to add a ClutterBinLayout::add() method which
adds an actor and sets the alignment policies without dealing with
variadic arguments functions and GValue (de)marshalling.
Use the LayoutManager API to set a back pointer to the Box actor
inside the LayoutManager used by the box.
This also allows us to replace the LayoutManager on a Box, since
the LayoutManager will be able to replace all the metadata if
needed.
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.
The ClutterBox::add method is a simple wrapper around the Container
add_actor() method and the LayoutManager layout properties API. It
allows adding an actor to a Box and setting the layout properties in
one call.
If the LayoutManager used by the Box does not support layout properties
then the add() method short-circuits out.
Along with the varargs version of the method there's also a vector-based
variant, for language bindings to use.
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.
Each actor managed by a BinLayout policy should reside inside its
own "layer", with horizontal and vertical alignment. The :x-align
and :y-align properties of the BinLayout are the default alignment
policies, which are copied to each new "layer" when it is created.
The set_alignment() and get_alignment() methods of BinLayout can
be changed to operate on a specific "layer".
The whole machinery uses the new ChildMeta support inside the
LayoutManager base abstract class.
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.
Emit the ::layout-changed when the BinLayout alignment policies change.
This will result in a queue_relayout() on the containers using the
BinLayout layout manager.
* Use ::layout-changed to queue a relayout when the layout changes
* Destroy the Box children when destroying the Box
* Allow getting the layout manager from the Box
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.
A BinLayout is a simple layout manager that allocates a single cell,
providing alignment on both the horizontal and vertical axis.
If the container associated to the BinLayout has more than one child,
the preferred size returned by the layout manager will be as big as
the maximum of the children preferred sizes; the allocation will be
applied to all children - but it will still depend on each child
preferred size and the BinLayout horizontal and vertical alignment
properties.
The supported alignment properties are:
* center: align the child by centering it
* start: align the child at the top or left border of the layout
* end: align the child at the bottom or right border of the layout
* fill: expand the child to fill the size of the layout
* fixed: let the child position itself
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.
