Added isHiding field to _ClutterStageOSX to allow windowDidResignKey
delegate to not order full screen window back whilst the full screen
window was being hidden. This caused other application windows to be
hidden. Also added code to keep hidden stage windows from being listed
in the application's Windows menu.
https://bugzilla.gnome.org/show_bug.cgi?id=655311
Added -windowDidChangeScreen: delegate to handle condition where moving
host window to a different screen would cause pick errors to be output.
The delegate just causes the stage to be redrawn which re-creates the
pick buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=655306
The Animatable interface allows object classes to provide and animate
properties outside of the usual GObject property introspection API.
This change allows ClutterState to defer to the animatable objects the
property introspection and animation, just like ClutterAnimation does.
The animate_property() method of the Animatable interface is far less
than optimal:
• it has a direct reference to ClutterAnimation;
• it has an interval decomposed as two values.
These issues tie the Animatable interface with the Animation object,
even though it's neither necessary nor future-proof.
Let's introduce a new method, interpolate_value(), which does not
reference ClutterAnimation and uses a ClutterInterval to express the
initial and final states.
All ClutterModelIter virtual functions have a default implementation,
and G_TYPE_INSTANCE_GET_CLASS cannot return NULL unless in case of a
catastrophic event in the type system - which will most likely blow up
any application code way before you could call a ModelIter method.
Thus, the idiom:
klass = CLUTTER_MODEL_ITER_GET_CLASS (instance);
if (klass && klass->vfunc)
klass->vfunc (instance);
is utterly useless complication, and it can be perfectly replaced by:
CLUTTER_MODEL_ITER_GET_CLASS (instance)->vfunc (instance);
without any loss of safety.
Currently, only clutter_model_iter_set_valist() is in charge of emitting
the ClutterModel::row-changed signal. Both the set() and the
set_valist() functions can be called with multiple columns, so we
coalesce the signal emission at the end of the set_valist(), to have a
single ::row-changed emission per change.
The clutter_model_iter_set_value() function is just a thin wrapper
around the set_value() virtual function, but since it's called
internally we cannot add the signal emission there as well, as we'd
break the signal coalescing.
For this reason, we need some code refactoring inside the various set()
variants of ClutterModelIter:
- we only use the internal va_arg variant for both the set() and
set_valist() public functions, to avoid multiple type checks;
- the internal set_valist() calls an internal set_value() method
which calls the virtual function from the iterator vtable;
- a new internal emit_row_changed() method is needed to retrieve
the ClutterModel from the iterator, and emit the signal;
Now, all three variants of the value setter will call an internal
ClutterModelIter::set_value() wrapper, and emit the ::row-changed
signal.
To check that the intended behaviour has been implemented, and it's not
going to be broken, the test suite has grown a new unit which populates
a model and changes a random row.
Cally was initially created with Clutter 0.6 in mind. To check
recursively the visibility of a actor a custom method was added.
Since 0.8.4 clutter_actor_get_pain_visibility provides
the same functionality.
Also removed a dummy method. Lets add methods that provide a real
functionality.
Keeping the backing Cairo surface of a CairoTexture canvas in sync with
the actor's allocation is tedious and prone to mistakes. We can
definitely do better by simply exposing a property that does the surface
resize and invalidation automagically on ::allocate.
The current "create context/draw/destroy context" pattern presents
various problems. The first issue is that it defers memory management to
the caller of the create() or create_region() methods, which makes
bookkeeping of the cairo_t* harder for language bindings and third party
libraries. The second issue is that, while it's easier for
draw-and-forget texturs, this API is needlessly complicated for contents
that have to change programmatically - and it introduces constraints
like calling the drawing code explicitly after a surface resize (e.g.
inside an allocate() implementation).
By using a signal-based approach we can make the CairoTexture actor
behave like other actors, and like other libraries using Cairo as their
2D drawing API.
The semantics of the newly-introduced ::draw signal are the same as the
one used by GTK+:
- the signal is emitted on invalidation;
- the cairo_t* context is owned by the actor;
- it is safe to have multiple callbacks attached to the same
signal, to allow composition;
- the cairo_t* is already clipped to the invalidated area, so
that Cairo can discard geometry immediately before we upload
the texture data.
There are possible future improvements, like coalescing multiple
invalidations inside regions, and performing clipped draws during
the paint cycle; we could even perform clipped redraws if we know the
extent of the invalidated area.
Some of the tests are making direct GL calls. Eventually we want
Clutter not to link directly against any GL library so that it can
leave Cogl to load it dynamically. As a step towards getting this to
work this patch changes the tests to resolve the symbols using
cogl_get_proc_address instead of linking directly.
ClutterTexture relies too much on GError, even for things that are
clearly programmer errors. Also, no error message passed to GError
is marked for translation as it should.
We should move the programmer errors, like passing the wrong bpp
value with regards to the presence of the alpha channel, to real
warnings; we should also try and harmonize all the error messages,
and not mention Cogl — especially in the ones marked for translation.
This avoids explicitly including gl or egl headers in
clutter-egl-headers.h. We were getting build failures when building
clutter against a libcogl that has runtime support for GL and GLES
because cogl-defines.h was including gl.h and then clutter-egl-headers.h
was later including GLES2/gl.h with typedef conflicts. Clutter relies on
Cogl to abstract GL and GLES and the winsys APIs like EGL and GLX so
Clutter should just rely on cogl.h to include the appropriate egl.h in
clutter-egl-headers.h.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Setting up the call and calling the GClosure was showing up in profiles
and seemed an easy one to remove.
Instead of calling the closure, let's remember the alpha func and the
user_data when possible (ie set_mode() and set_func()) and use it in
get_alpha().
https://bugzilla.gnome.org/show_bug.cgi?id=654727
The "editable" property is documented to default to TRUE, but is
initialized to FALSE in the _init() function.
Third party code would be affected if we changed the default to be
TRUE, so we have to change the default value in the GParamSpec.
https://bugzilla.gnome.org/show_bug.cgi?id=654726
When emitting a new-frame signal, priv->elapsed_time is passed as a
parameter. This is a gint64. The closure marshal uses an INT. On some
platforms, this is not received correctly by signal handlers (they
receive 0). One solution is to cast priv->elapsed_time to a gint when
emitting the signal.
We cannot change the signature of the signal without breaking ABI.
https://bugzilla.gnome.org/show_bug.cgi?id=654066
If the meta for the animation property is not found, the name of the
property to look for is still from the token, and we need to free the
memory allocated for it.
https://bugzilla.gnome.org/show_bug.cgi?id=654656
Clutter may be used together with GTK+, which indirectly may use
XInput2 too, so the cookie data must persist when both are handling
events.
What happens now in a nutshell is, Clutter is only guaranteed to allocate
the cookie itself after XNextEvent(), and only frees the cookie if its
XGetEventData() call allocated the cookie data.
The X[Get|Free]EventData() calls happen now in clutter-event-x11.c as
hypothetically different event translators could also handle other set
of X Generic Events, or other libraries handling events for that matter.
