When Clutter tries to pick an ARGB visual it tried to set the
GLX_TRANSPARENT_TYPE attribute of the FBConfig to
GLX_TRANSPARENT_RGB. However the code to do this was broken so that it
was actually trying to set the non-existant attribute number 0x8008
instead. Mesa silently ignored this so it appeared as if it was
working but the Nvidia drivers do not like it.
It appears that the TRANSPARENT_TYPE attribute is not neccessary for
getting an ARGB visual anyway and instead it is intended to support
color-key transparency. Therefore we can just remove it and get all of
the FBConfigs. Then if we need an ARGB visual we can just walk the
list to look for one with depth == 32.
The fbconfig is now stored in a single variable instead of having a
separate variable for the rgb and rgba configs because the old code
only ever retrieved one of them anyway.
Previously when the markup property is set it would generate an
attribute list from the markup and then merge it with the attributes
from the attribute property and store it as the effective
attributes. The markup attributes and the marked up text would then be
forgotten. This breaks if the application then later changes the
attributes property because it would try to regenerate the effective
attributes from the markup text but the stored text no longer contains
any markup. If the original markup text happened to contain entities
like '<' they would end up causing parse errors because they would
be converted to the actual symbols.
To fix this the attributes from the markup are now stored
independently from the effective attributes. The effective attributes
are now regenerated if either set of attributes changes right before a
layout is created.
http://bugzilla.openedhand.com/show_bug.cgi?id=1940
Destroy the dummy XImage we create even on success.
http://bugzilla.openedhand.com/show_bug.cgi?id=1918
Based on a patch by: Carlos Martín Nieto <carlos@cmartin.tk>
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
PropertyInfo should store a copy of the JsonNodes it references, so
that property_info_free() can safely dispose them, and we can reference
values across different UI definition data.
The implicit timeline parsing code is not copying the JsonNode; this
leads to a double free in some cases, which is masked by the GSlice
allocator and produces a heap corruption later on.
Allow the user of the ClutterMedia interface to specify an external (as
in not multiplexed with the audio/video streams) location of a subtitle
stream.
Both the ::insert-text and ::delete-text are "action" signals, that is
signals that are safe to (and should) be emitted using g_signal_emit()
directly.
A timeline advancement might cause another timeline to be
destroyed, which will likely lead to a segmentation fault.
Before advancing the timelines we should take a reference
on them - just like we do for the stages before doing
event processing. This will prevent dispose() from running
until the end of the advancement.
http://bugzilla.openedhand.com/show_bug.cgi?id=1854
Apparently, calling g_set_prgname() multiple times is not allowed
anymore, and hence clutter_init_* calls should not do that. Though this
is really GLib's fault - and a massive nuisance for us - we should
prolly comply to avoid the test suite dying on us.
* animate-layout-manager:
layout-manager: Document the animation support
layout-manager: Rewind the timeline in begin_animation()
box-layout: Remove the allocations hash table
docs: Clean up the README file
layout: Let begin_animation() return the Alpha
box-layout: Add knobs for controlling animations
box-layout: Animate layout properties
layout: Add animation support to LayoutManager
Add ActorBox animation methods
Add a section inside the LayoutManager class API reference documenting,
with examples, how to implement animation support inside a layout
manager sub-class.
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.
The BoxLayout uses a HashTable to map the latest stable allocation of
each child, in order to use that as the initial value during an
animation; this in spite of already having a perfectly valid per-child
storage as part of the layout manager: ClutterBoxChild.
The last stable allocation should be stored inside the ClutterBoxChild
instead of having it in the private data for ClutterBoxLayout. The
access remains O(1), since there is a 1:1 mapping between child and
BoxChild instances, but we save a little bit of memory and we avoid
keeping aroud allocations for old children.
* stage-use-alpha:
tests: Use accessor methods for :use-alpha
stage: Add accessors for :use-alpha
tests: Allow setting the stage opacity in test-paint-wrapper
stage: Premultiply the stage color
stage: Composite the opacity with the alpha channel
glx: Always request an ARGB visual
stage: Add :use-alpha property
materials: Get the right blend function for alpha
ClutterActor checks, when destroying and reparenting, if the parent
actor implements the Container interface, and automatically calls the
remove() method to perform a clean removal.
Actors implementing Container, though, might have internal children;
that is, children that are not added through the Container API. It is
already possible to iterate through them using the Container API to
avoid breaking invariants - but calling clutter_actor_destroy() on
these children (even from the Container implementation, and thus outside
of Clutter's control) will either lead to leaks or to segmentation
faults.
Clutter needs a way to distinguish a clutter_actor_set_parent() done on
an internal child from one done on a "public" child; for this reason, a
push/pop pair of functions should be available to Actor implementations
to mark the section where they wish to add internal children:
➔ clutter_actor_push_internal ();
...
clutter_actor_set_parent (child1, parent);
clutter_actor_set_parent (child2, parent);
...
➔ clutter_actor_pop_internal ();
The set_parent() call will automatically set the newly added
INTERNAL_CHILD private flag on each child, and both
clutter_actor_destroy() and clutter_actor_unparent() will check for the
flag before deciding whether to call the Container's remove method.
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.
ClutterLayoutManager does not have any state associated with it, and
defers all the state to its sub-classes.
The BoxLayout is thus in charge of controlling:
• whether or not animations should be used
• the duration of the animation
• the easing mode of the animation
By adding three new properties:
• ClutterBoxLayout:use-animations
• ClutterBoxLayout:easing-duration
• ClutterBoxLayout:easing-mode
And their relative accessors pairs we can make BoxLayout decide whether
or not, and with which parameters, call the begin_animation() method of
ClutterLayoutManager.
The test-box-layout has been modified to reflect this new functionality,
by checking the key-press event for the 'a' key symbol to toggle the use
of animations.
Use the newly added animation support inside LayoutManager to animate
between state changes of the BoxLayout properties.
The implementation is based on equivalent code from Mx, written by:
Thomas Wood <thomas.wood@intel.com>
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.
ClutterActorBox should have an interpolate() method that allows to
compute the intermediate values between two states, given a progress
value, e.g.:
clutter_actor_box_interpolate (start, end, alpha, &result);
Another utility method, useful for layout managers, is a modifier
that clamps the members of the actor box to the nearest integer
value.
When getting signals from higher level toolkits, occasionally
one wants access to the underlying event; say for a Button
widget's "clicked" signal, to get the keyboard state.
Rather than having all of the highlevel widgets emit
ClutterEvent just for the more unusual use cases,
add a global function to access the event state.
http://bugzilla.openedhand.com/show_bug.cgi?id=1888
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Old-style X11 terminals require that even modern X11 send KeyPress
and KeyRelease pairs when auto-repeating. For this reason modern(-ish)
API like XKB has a way to detect auto-repeat and do a single KeyRelease
at the end of a KeyPress sequence.
The newly added check emulates XKB's detectable auto-repeat by peeking
the next event after a KeyRelease and checking if it's a KeyPress for
the same key and timestamp - and then ignoring the KeyRelease if it
matches.
If a Stage has been set to use a foreign Window then Clutter should not
be managing it; calling XWithdrawWindow and XMapWindow should be
reserved to the windows we manage ourselves.
