Instead of a single new() constructor that both allocates and
initializes, split the allocation and initialization into two separate
functions for types that are typically used on the stack, and rarely
allocated on the heap, like ClutterPoint and friends.
This is also applied retroactively to ClutterActorBox and ClutterVertex,
given that the same considerations on usage apply to them as well; we
can add a return value to clutter_actor_box_init() and
clutter_vertex_init() in an ABI-compatible way, so that
clutter_actor_box_new() and clutter_vertex_new() can be effectively
reimplemented as "init (alloc ())".
Using a compound type property for position and size has various
advantages: it reduces the amount of checks; it reduces the amount
of notify signals to connect to; it reduces the amount of transitions
generated.
The ClutterCanvas content implementation should be used instead, to
avoid stringing along the ClutterTexture API and implementation.
This change requires some minor surgery, as the deprecated section
already contains an header for the previously deprecated methods; plus,
we don't want to deprecate clutter_cairo_set_source_color(). This means
creating a new header to be used for Cairo-related API.
The get_distance() API uses machine integers to compute the distance;
this means that on 32bit we can overflow the integer size. This gets
hidden by the fact that get_distance() returns an unsigned integer as
well.
In reality, ClutterPath is an unmitigated mess, and the only way to
actually fix it is to break API.
https://bugzilla.gnome.org/show_bug.cgi?id=652521
This commit adds a further conditional check for calling
clutter_actor_show() when adding a child to an actor. We cannot
unconditionally change the value of the show-on-set-parent property like
the original solution of commit 81b19a78f5
as that breaks the document invariant that show-on-set-parent will be
changed iff an actor is without a parent.
The new ADD_CHILD_SHOW_ON_SET_PARENT flag is part of the default and
legacy flags, thus retaining the default behaviour when adding a child;
the flag is not passed when reordering the list of children, which means
we ignore the state of the show-on-set-parent property.
The conformance test suite fully passes, including the newly added test
to verify that changing the paint order does not trigger visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=674510
This reverts commit 81b19a78f5.
The commit breaks the conformance test unit for the invariants we
guarantee for the 1.x API:
ERROR:actor-invariants.c:307:actor_show_on_set_parent: assertion failed: (show_on_set_parent)
It's possible to run Clutter with the 'null' input backend, which means
that clutter_device_manager_get_default() may return NULL. In the future
we may add a default dummy device manager, but right now it's safer to
just add a simple NULL check in the places where we ask for the device
manager.
I can't think of any reason why it would do this and there's no
comment explaining it so let's just remove it. The global fog state
has been removed in Cogl 2.0 so it will cause problems later.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
CoglVertexBuffer is deprecated so here is a fairly simple replacement
to use the experimental CoglPrimitive API.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Drop a bunch of variables that are not meant to be used by Cally; also,
drop the wrong library name from the Libs key: Clutter has a single
shared library, now.
https://bugzilla.gnome.org/show_bug.cgi?id=674105
The interface looked like a good idea around the time Clutter 0.2 was
out, but in reality we never had a proper, and supported implementation
outside of clutter-gst - thus, ClutterMedia was acting like a wrapper
around GStreamer, leading to hilarious issues of impedence mismatch
between API and all sorts of indirection issues typical of wrong
abstractions.
In theory, ClutterMedia should have been deprecated and removed before
we hit 1.0, but we kept flip-flopping on the issue.
For 2.0, it's time to take it out.
And shoot it in the face.
It's been a year and change, and two stable releases, since we
introduced the paint volume mechanism to allow actors to paint outside
their allocation safely in environments that support clipped redraws.
The time has come to flip the switch, and return a valid paint volume,
matching the actor's allocation, by default - at least for Actor
instances from classes that do not override paint() and
get_paint_volume().
If an actor has a paint signal handler then it's the user responsability
not to paint outside the allocation - and to suffer the consequences of
doing so; in an ideal world, paint() would not be a signal in the first
place anyway. Plus, the idea that painting can happen at any time and
still have a valid surface greatly conflicts with the design goal of
making Clutter's rendering operations fully retained into a render tree.
We can still revert this commit before spinning 1.12, if need be.
When removing the last Action, Constraint, or Effect, we should also be
clearing the corresponding MetaGroup: code inside ClutterActor relies on
NULL checks, and changing them all to check for NULL && n_items == 0
would not be fun.
configure.ac defines XINPUT_2_2 if XI 2.2 support was found. The code
expects XINPUT_2_2 in the device manager, but HAVE_XINPUT_2_2 in the x11
backend.
On newer X servers, the latter causes a BadValue when XIQueryDevice sends a
different major/minor than gdk's device manager (gnome-control-center).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=673961
We need to remove the transition only if the current repeat is equal to
the number of repeats, and if the transition was marked as remove on
complete. Otherwise, the transition has to remain where it is.
The opacity internal setter will do it for us, and it will take into
consideration any eventual flatten effect applied to the actor.
This unbreaks the actor-offscreen-redirect conformance test.
The get_geometry() implementation is broken on multi-head systems; the
only solution is to use XRandR to get the size of the CRTC that contains
the stage.
In XInput 2, the proximity events of XInput 1 have been replaced by an
axis on a valuator class. This means that, on devices that support
proximity information, for instance pens of a tablet, you will start
receiving events with the distance as an axis value - similarly to how
the pressure and tilt are presented in the API.
We were using g_list_foreach() prior to the first Apocalypse, and that
function is resilient against changes to the list while iterating it;
since we are not using a GList any more, we need handle this case
ourselves.
This also avoids the warning
Cogl-WARNING **: ./cogl-buffer.c:215: GL error (1285): Out of memory
generated by cogl_buffer_map when the CoglBuffer has zero length.
When the easing state has a duration of zero milliseconds we can skip
the entire create_transition() call inside set_width() and set_height(),
to avoid what may be a costly call to get_preferred_*.
If we update a transition that is currently playing, we need to check
the current easing state, and look at the eventual duration, in case
the user wants to cancel the transition.
Instead of checking the duration of the current easing state we should
check if there's a transition in progress, and update it
unconditionally.
If there is no easing state, or the easing state has a duration of zero
milliseconds, then create_transition() should bail out early and set the
requested final state.
This allows us to write:
clutter_actor_save_easing_state (actor);
clutter_actor_set_x (actor, 200);
clutter_actor_restore_easing_state (actor);
[...]
clutter_actor_set_x (actor, 100);
and have the second set_x() update the easing in progress, instead of
being ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=672945
Commit 80626e7584 removed an
IN_DESTRUCTION check from within the add_child_internal() method,
outlining an option for bringing it back. It was too late for the 1.10
cycle to do it, and eventually pick up the pieces, but now that we're
at the beginning of the 1.11 cycle we can restore it, and add checks
elsewhere to balance it.
This patch fixes clutter to not crash when multiple animations share
the same timeline and the actors are explicitly destroyed before
the timeline completes (bug 672890)
Some of the Clutter code was using GL types for the primitive types
such as GLint and GLubyte and then passing these to Cogl. This doesn't
make much sense because the Cogl functions directly take native C
types. This patch just replaces them with either a native C type or a
glib type.
Some of the cogl conformance tests are trying to directly call GL for
example to test creating a foreign texture. These tests have been
changed to manually define the GL enum values instead of relying on a
GL header to define them.
This is necessary because Cogl may soon stop including a GL header
from its public headers.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The disjunction operator was misspelt as -O which tests whether the
following file is owned by the calling user. This doesn't take enough
arguments so bash was showing an error and the test was always
failing. This meant that NEED_XKB_UTILS was always false which should
have broken the build but the Makefile was mistakenly including
clutter-xkb-utils.c again if SUPPORT_WAYLAND is defined.
See 1b77565e for reference.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The commit 90e5088 added some extra compiler warning options that were
triggering warnings when enabling the wayland build due to missing
header includes. This adds those header includes in.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Because the wayland-server-protocol.h header includes symbols that
collide with wayland-client-protocol.h Cogl now provides top level
<cogl/cogl-wayland-server.h> and <cogl/cogl-wayland-client.h> headers so
that applications can ensure they only include one of the wayland
protocol headers in a particular compilation unit. This updates clutter
accordingly to include those headers.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Should not have been there in the first place: the animatable will be
set either using ClutterTransition API, or when adding the transition
to a ClutterActor.
When adding a transition to a ClutterActor, the actor should hold a
reference on it, and release it only when we remove it. This makes
transitions just like other objects held by ClutterActor.
The ::completed signal emission is part of the current cycle; repeating,
like the automatic reverse of the timeline's direction, happens after
the ::completed chain of handlers has been called.
We still use XKeycodeToKeysym() in a fallback path in case we're not
running on a decent enough system; XKeycodeToKeysym() is deprecated as
of version 1.12 of the X server, but since I don't want to copy a bunch
of code from GDK or, god forbid, from Xlib, for a fallback path, it's
probably more reasonable to just silence the compiler warnings - at
least until we can drop all the X compatibility crap, and just use
modern, or semi-modern, API.
Some events may contain precise scrolling information coming from
devices like trackpads and touchscreens. ClutterEvent should allow
setting and getting this information.
While you can get a per-transition notification of completion, it can be
convenient to also have a way to notify that all the transitions
involving an actor are complete. A simple signal triggered by the
removal of the last transition fits the bill pretty neatly.
When handling Configure events from the X server we update the
internal copy of the window size. Unfortunately we may be updating the
wrong stage implementation because we use the one related to the event
translator (which is the first created stage).
This patch fix flickering/redrawning issues with multi-stage by
looking for the right stage implementation associated with an XEvent.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
If restore_easing_state() is called on the last easing state on the
stack, clean up the stack, so that we don't leave stale pointers
around to later segfault on.
When setting the easing mode, duration, or delay without having ever
called clutter_actor_save_easing_state(). It's confusing, and not
really nice.
In the future, we'll have a default easing state implicitly created by
the actor itself, but for the time being explicitly opting in is
preferrable.
If the pointer is inside the window frame when it's shown then we need
to synthesize and emit a NSMouseEnterEvent ourselves, as Quartz won't
do it for us.
This is a bit of a blind commit - but it's taken from an equivalent
patch that has been verified to work in GDK.
Yes, it's not really the proper GL name for a linear-on-every-axis of a
texture plus linear-between-mipmap-levels minification filter, but it
has three redeeming qualities as a name:
- LINEAR_MIPMAP_LINEAR sucks, as it introduces GL concepts like
mipmaps in the API naming, while we're trying to avoid that;
- people using GL already know what 'trilinear' means in this context
without going all Khronos on their asses;
- we're using 2D textures anyway, so 'linear on two axes and linear
between mipmap levels' can be effectively approximated to
'trilinear'.
I mean, if even the OpenGL official wiki says:
Unfortunately, what most people think of as "trilinear" is not linear
filtering of a 3D texture, but what in OpenGL terms is GL_LINEAR mag
filter and GL_LINEAR_MIPMAP_LINEAR in the min filter in a 2D texture.
That is, it is bilinear filtering of each appropriate mipmap level,
and doing a third linear filter between the adjacent mipmap levels.
Hence the term "trilinear".
-- http://www.opengl.org/wiki/Texture
then the horse has already been flogged to death, and I don't intend to
be accused of necrophilia and sadism by flogging it some more.
Prior art: every single GL tutorial in the history of ever;
CoreAnimation's scaling filter enumerations.
If people want to start using 1D or 3D textures they they are probably
going to be using Cogl API directly, and that has the GL naming scheme
for minification and magnification filters anyway.
At least for the time being, we only expose the parts of the API that we
want to use internally and for new, out-of-tree Content implementations.
The full PaintNode tree API will be made public in 1.12 once we branch
master.
It's a bit late in the game for changing the emission of the paint
signal with actors that use paint nodes - mostly because we have both
implicit paint nodes (background color, content) and explicit paint
nodes (the paint_node virtual).
When we branch for 1.12 we can revert this change.
It's safer, and consistent with the rest of Clutter, to make sure that
the template pipeline we use for ClutterTextureNode has its wrap mode
set to clamp-to-edge.
Both ClutterCanvas and ClutterImage should use the minification and
magnification filters set on the actor, just like the use the content
box and the paint opacity.
The ::paint signal is the old way to paint an actor; the paint_node()
virtual function is the new way. It's still not possible to traverse the
whole scene graph and build a render tree of PaintNode instances, but
with this change we simultaneously cut out the ::paint signal emission
from the critical path for actors that are using the new PaintNode-based
API, and we retain backward compatibility in the interim period between
1.10 and 2.0.
Instead of our homegrown string building; this at least ensures that
we're generating proper data, instead of random strings. Plus, using
JsonNode and JsonBuilder, we can ask the PaintNode subclasses to
serialize themselves in a sensible way.
ClutterContent is an interface for creating delegate objects that handle
what an actor is going to paint.
Since they are a newly added type, they only hook into the new PaintNode
based API.
The position and size of the content is controlled in part by the
content's own preferred size, and by the ClutterContentGravity
enumeration.
The ::paint-node virtual inside ClutterActor is what we want people to
use when painting their actors.
Right now, it's a new code path, that gets called while painting; the
paint_node() implementation should only paint the actor itself, and not
its children — they will get their own paint_node() called when needed.
Internally, ClutterActor will automatically create a dummy PaintNode and
paint the background color; then control will be handed out to the
implementation on the class. This is required to maintain compatibility
with the old ::paint signal emission.
Once we are able to get rid of the paint (and pick) sequences, we'll
switch to a fully retained render tree.
Now that we have a proper scene graph API, we should split out the
rendering part from the logical and event handling part.
ClutterPaintNode is a lightweight fundamental type that encodes only the
paint operations: pipeline state and geometry. At its most simple, is a
way to structure setting up the programmable pipeline using a
CoglPipeline, and submitting Cogl primitives. The important take away
from this API is that you are not allowed to call Cogl API like
cogl_set_source() or cogl_primitive_draw() directly.
The interesting approach to this is that, in the future, we should be
able to move to a purely retained mode: we will decide which actors need
to be painted, they will update their own branch of the render graph,
and we'll take the render graph and build all the rendering commands
from that.
For the 1.x API, we will have to maintain invariants and the existing
behaviour, but as soon as we can break API, the old paint signal will
just go away, and Actors will only be allowed to manipulate the render
tree.
As it turns out, we do end up recursing inside the ::paint signal
emission - especially inside the conformance test suite.
This thoroughly sucks - and we'll only be able to fix it properly
when we bump API for 2.0.
ClutterActor should be able to hold all transitions, even the ones that
have been explicitly created.
This will allow to add new transitions types in the future, like the
keyframe-based one, or the transition group.
It should be possible to ask a timeline what is its duration, taking
into account eventual repeats, and which repeat is the one currently
in progress.
These two functions allow writing animations that depend on the current
state of another timeline.
It should be possible to set up the delay of a transition, but since
we start the Transition instance before returning control to the caller,
we cannot use clutter_actor_get_transition() to do it without something
extra-awkward, like:
transition = clutter_actor_get_transition (actor, "width");
clutter_timeline_stop (transition);
clutter_timeline_set_delay (transition, 1000);
clutter_timeline_start (transition);
for each property involved. It's much easier to add a delay to the
easing state of an actor.
Clutter is meant to be, and I quote from the README, a toolkit:
for creating fast, compelling, portable, and dynamic graphical
user interfaces
and yet the default mode of operation for setting an actor's state on
the scene graph (position, size, opacity, rotation, scaling, depth,
etc.) is *not* dynamic. We assume a static UI, and then animate it.
This is the wrong way to design an API for a toolkit meant to be used to
create animated user interfaces. The default mode of operation should be
to implicitly animate every state transition, and only allow skipping
the animation if the user consciously decides to do so — i.e. the design
tenet of the API should be to make The Right Thing™ by default, and make
it really hard (or even impossible) to do The Wrong Thing™.
So we should identify "animatable" properties, i.e. those properties
that should be implicitly animated by ClutterActor, and use the
animation framework we provide to tween the transitions between the
current state and the desired state; the implicit animation should
happen when setting these properties using the public accessors, and not
through some added functionality. For instance, the following:
clutter_actor_set_position (actor, newX, newY);
should not make the actor jump to the (newX, newY) point; it should
tween the actor's position between the current point and the desired
point.
Since we have to maintain backward compatibility with existing
applications, we still need to mark the transitions explicitly, but we
can be smart about it, and treat transition states as a stack that can
be pushed and popped, e.g.:
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_position (actor, newX, newY);
clutter_actor_set_opacity (actor, newOpacity);
clutter_actor_restore_easing_state (actor);
And we can even start stacking animations, e.g.:
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_position (actor, newX, newY);
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_easing_mode (actor, CLUTTER_LINEAR);
clutter_actor_set_opacity (actor, newOpacity);
clutter_actor_set_depth (actor, newDepth);
clutter_actor_restore_easing_state (actor);
clutter_actor_restore_easing_state (actor);
And so on, and so forth.
The implementation takes advantage of the newly added Transition API,
which uses only ClutterTimeline sub-classes and ClutterInterval, to cut
down the amount of signal emissions and memory management of object
instances; as well of using the ClutterAnimatable interface for custom
properties and interpolation of values.
As a convenience for the C API.
Language bindings should already be using the GValue variants.
This commit also moves the custom progress functions out of the
clutter-interval.c, as they are meant to be generic interpolation
functions and not ClutterInterval-specific.
