When calculating the union of a volume with an empty volume we aim to
simply take the contents of the non-empty volume, but we were not
copying the flags across. We now use
_clutter_paint_volume_set_from_volume which copies all the flags except
the is_static flag.
In _clutter_paint_volume_set_from_volume we were using memcpy to simply
copy everything from one volume to another, but that meant we were
trashing the is_static flag which determines if the destination
paint-volume was slice allocated or not.
This removes the constraint that a paint-volume must be axis aligned
before _clutter_paint_volume_complete can be called. NB: A paint volume
is represented by one origin vertex and then three axis vertices to
define the width, height and depth of the volume. It's straightforward
to use the vectors from the origin to the axis vertices to deduce the
other 4 vertices so we can remove the is_axis_aligned assertion.
Since eef9078f the translation of the camera away from the z=zero
plane was hardcoded at 50 which is approximately half way between the
default z_near and z_far values. This ended up with quite a small
distance in user-space coordinates to the far plane with the default
stage size and this was causing test-texture-quality to clip the actor
early.
This patch makes it try to calculate a reasonable value for the
position of the z=0 plane as well as a value for z_far so we maximize
the space in between the z=0 plane and the near plane and we have a
predictable amount of space behind the stage before hitting the far
clipping plane, while considering the trade off of loosing depth
precision by pushing the far plane too far back relative to the near
plane.
With the default fov of 60° it's not possible to use the stage size to
define the gap in-front of the stage plane; only ~87% of the stage size
is possible as an upper limit. We make 85% of the stage_height available
assuming you have a fov of 60°. We consistently provide 10 times the
stage height of space behind the stage regardless of the fov.
It seems worth noting here that we went around in circles a few times
over how to calculate the gaps since there are a number of trade offs to
consider and they also affect the complexity of the solution. In the end
we went for simplicity but commented the issues well enough hopefully so
we can develop a more elaborate solution if we ever have a use-case.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2625
Since eef9078f ClutterStage updates the aspect ratio of the
perspective matrix whenever the size of the stage changes. This meant
that if an application tries to set its own perspective matrix then
part of it would get overridden. It's not really clear what the
use-case of setting the perspective on the stage should be but it
seems like the safest bet is to always try to preserve the
application's request. The documentation for the function has been
tweaked to discourage its use.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2625
Some parts of the StageWindow interface aren't meaningful for all window
systems. This makes stage_window_set_title/fullscreen/cursor_visible
optional instead of requiring those window systems to implement empty
stubs. Notably the empty stubs we had in the Cogl backend (previously
the EGL backend) used g_warning to report the feature as unsupported and
that was causing conformance test failures.
Since GLX and EGL are abstracted by Cogl the two backends are both
implementing everything using the Cogl API and they are almost
identical.
This updates the egl backend to support everything that the glx backend
supports. Now that EGL and GLX are abstracted by Cogl, the plan is that
we will squash the clutter-egl/glx backends into one. Since the EGL
backend in clutter can conditionally not depend on X11 we will use the
EGL backend as the starting point of our common backend.
https://bugzilla.gnome.org/show_bug.cgi?id=649826
We hadn't updated the egl backend inline with a change to the arguments
that cogl_onscreen_x11_set_foreign_window_xid would expect and that was
causing a compilation error.
* swipe-action:
test-swipe-action: Clean up the test code
docs: Add the new actions to the API reference
gesture-action: Remove the multi-device entry points
swipe-action: Remove the required devices call
swipe-action: Clean up
gesture-action: Clean up
Add ClutterSwipeAction and ClutterGestureAction
Do not just allow animating states connected to signals: add a "warp"
optional key that ends up calling clutter_state_warp_to_state(). This
is useful for debugging.
Currently, defining states for object signals can only be done by
defining a ClutterState inside the ClutterScript definition. We should
allow creating a (named) ClutterState in code, and associating it to a
ClutterScript instance — and have the Script resolve the "state" field
of a signal definition correctly.
One of the uses of a ClutterState state machine along with ClutterScript
is to provide a quick way to transition from state to state in response
to signal emitted on specific instances.
Connecting a real function, in code, to a specific signal does not
improve the ease of use of ClutterScript to define scenes.
By adding a new signal definition to the current one we can have both a
simple way to define application logic in code and in the UI definition
file.
The new syntax is trivial:
{
"name" : <signal name>,
"state" : <state machine script id>,
"target-state" : <target state>
}
The ClutterState instance is identified by its script id, and the target
state is resolved at run-time, so it can be defined both in
ClutterScript or in code. Ideally, we should find a way to associate a
default ClutterState instance to the ClutterScript one that parses the
definition; this way we would be able to remove the "state" member, or
even "style" the behaviour of an object by replacing the ClutterState
instance.
The implementation uses a signal emission hook, to avoid knowing the
signal signature; we check the emitter of the signal against the object
that defined the signal, to avoid erroneous state changes.
cairo.h is intended to be included as <cairo.h> not <cairo/cairo.h> as
is the style for clutter.h. If you have installed cairo to a custom
prefix then using cairo/cairo.h can result in unintentional use of the
system cairo headers, or if they aren't installed then it will result in
a failure to find the header.
GestureAction supports a single device/touch point. We'll need touch
events supported in Clutter before adding the ability to set required
device/touch points on gestures.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2585
The GestureAction is marked as abstract, but it has a constructor. It
should be possible to create simple gesture recognizers through signal
handling alone, so we might as well have GestureAction be a concrete
class from the start.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2585
Previously ClutterText was just reporting the allocation as the paint
volume. The preferred size of a ClutterText is just the logical
rectangle of the layout. A pango layout can sometimes draw outside of
its logical rectangle for example with an italicised font with large
serifs. Additionally, ClutterText doesn't make any attempt to clip the
text if the actor gets allocated a size too small for the text so it
would also end up drawing outside of the paint volume in that case. To
fix this, the paint volume is now reported as the ink rect of the
Pango layout. The rectangle for the cursor and selection is also
unioned into that because it won't necessarily be within the ink
rectangle.
The function for drawing the selection rectangles has been split up
into a generic function that calculates the rectangles that need to be
drawn and a function that draws them. That way the get_paint_volume
virtual can share the code to calculate the rectangles.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2599
When the cursor is at the leftmost position in the text the drawn
pixel position is moved to the left by the size of the cursor. There's
no explanation for why this happens and it doesn't seem to make any
sense so this patch removes it. It makes multi-line texts looks odd
because the cursor ends up at a different horizontal position when it
is on the first line from any other line. It also makes using
priv->cursor_pos difficult in any other part of the code because the
paint function modifies it.
The original patch that added this can be traced back to Tidy commit
c356487c15. There's no explanation in the commit message either.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2599
A long press is a special form of click action; the default
implementation uses a single signal with multiple states: query, action
and cancel. On click we use the "query" state to check whether the
ClutterClickAction supports long presses; if the callback returns TRUE
then we install a timeout and we either emit the "activate" state when
the timeout expires or we emit the "cancel" state if the pointer leaves
the actor, or if the pointer moves outside a certain threshold. If the
long press reached the "activate" state then we skip the clicked signal
emission.
A property to control the minimum time that has to elapse before a press
is recognized as a long press. This will be used by ClutterClickAction,
but it can be shared across touch-based gestures.
The G_CONST_RETURN define in GLib is, and has always been, a bit fuzzy.
We always used it to conform to the platform, at least for public-facing
API.
At first I assumed it has something to do with brain-damaged compilers
or with weird platforms where const was not really supported; sadly,
it's something much, much worse: it's a define that can be toggled at
compile-time to remove const from the signature of public API. This is a
truly terrifying feature that I assume was added in the past century,
and whose inception clearly had something to do with massive doses of
absynthe and opium — because any other explanation would make the
existence of such a feature even worse than assuming drugs had anything
to do with it.
Anyway, and pleasing the gods, this dubious feature is being
removed/deprecated in GLib; see bug:
https://bugzilla.gnome.org/show_bug.cgi?id=644611
Before deprecation, though, we should just remove its usage from the
whole API. We should especially remove its usage from Cally's internals,
since there it never made sense in the first place.
If an actor or the stage to which it belongs are being destroyed then
there is no point in queueing a redraw that will not be seen anyway.
Bailing out early also avoids the case in which a redraw is queued
during destruction wil cause redraw entries will be added to the Stage,
which will take references on it and cause the Stage never to be
finalized.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2652
