-Combine entries in the property sheets and make it a bit more flexible,
and drop some redundant items
-Use Custom Build Rules for generating enumeration and marshalling sources,
and the .def file so that they can be wiped off when a "clean" is
requested, and regenerate automatically when the templates/.symbols
files are updated.
-Improve consistency by using ApiVersion rather than ClutterApiVersion
with the Visual Studio project for other components of the Clutter/GTK+
stack
-Get rid of unneeded configs in the "install" project
-Combine entries in the property sheets and make it a bit more flexible,
and drop some redundant items
-Use Custom Build Rules for generating enumeration and marshalling sources,
and the .def file so that they can be wiped off when a "clean" is
requested, and regenerate automatically when the templates/.symbols
files are updated.
-Improve consistency by using ApiVersion rather than ClutterApiVersion
with the Visual Studio project for other components of the Clutter/GTK+
stack
-Get rid of unneeded configs in the "install" project
This is taken directly from the 1.16 series, as it seems that the 1.x
development starts from here, so put this here first and make the
neccessary adjustments as we go on.
This reverts commit b6fc4a810f.
It seems that the Cogl/Cogl-Path split was not meant to break API/ABI,
so we should not check for a new dependency. Let's revert the commit,
and wait for Cogl to get fixed instead.
If we don't get passed a CoglFramebuffer when creating the root paint
node then we ask Cogl to give us the current draw buffer.
This allows the text-cache conformance test to pass, but it'll require
further investigation.
Currently the default values according to their param spec don't
match the actually used defaults, so update the former to reflect
the actual behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Whether a child should receive extra space should be determined
by the expand property, not [xy]_fill (which just determine how
additional space should be used). The behavior is already correct
when using the ClutterActor:[xy]_expand properties, but needs
fixing for the corresponding ClutterBoxLayoutChild property.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Just as BoxLayout, BinLayout uses an odd interpretation of the box
passed into allocate(): to define a child area of (w x h) starting at
(x, y), callers need to pass a box of (x, 2 * x + w, y, 2 * y + h).
This behavior is just confusing, change it to use the full box for
child allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Currently, BoxLayout interprets the box passed into allocate() in
a fairly peculiar way:
- in the direction of the box, all space between [xy]1 and [xy]2
is distributed among children (e.g. children occupy the entire
width/height of the box, offset by [xy]1)
- in the opposite direction, expanded children receive space
between [xy]1 and the height/width of the box (e.g. children
occupy the width/height of the box minus [xy]1, offset by [xy]1)
The second behavior doesn't make much sense, so adjust it to interpret
the box parameter in the same way as the first one.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
The implicitly created transitions are removed when complete by the
implicit transition machinery. The remove-on-complete hint is for
user-provided transitions.
https://bugzilla.gnome.org/show_bug.cgi?id=705739
ClutterTransition:remove-on-complete uses the ClutterTimeline::stopped
signal, as it's the signal that tells us that the timeline's duration
has fully elapsed.
Mouse wheel events come as EV_REL/REL_WHEEL, and we can convert
them to clutter events on the assumption that scrolling with
the wheel is always vertical.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
xkb_state_update_key() needs to be called only on state transitions,
otherwise the state tracking gets confused and locks certain modifiers
forever.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
A wayland compositor needs to have more keyboard state than
ClutterModifierState exposes, so it makes sense for it to use
xkb_state directly. Also, it makes sense for it to provide
it's own keymap, to ensure a consistent view between the compositor
and the wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=705710