We want to be able to deprecate macros, but right now the best we can do
is to wrap them with things like:
#ifndef CLUTTER_DISABLE_DEPRECATED
# define A_MACRO_I_WANT_TO_DEPRECATE ...
#endif
Which requires adding a new symbol to the build, and will cause a build
error instead of a compiler/pre-processor warning.
Fortunately, we can use the _Pragma() keyword introduced by C99 and
supported by GCC to add a warning to the output, while leaving the macro
itself intact.
GCC does not have a "deprecated" pragma, so we have to use a generic
warning; this also means we cannot do nifty things like concatenating
strings and the like, as we do for the "deprecated" attribute.
The macro deprecation symbol should have the same affordances as the
function deprecation one, and evaluate to nothing if the required
version is lower than the current version; or if the global toggle for
deprecation warnings is in effect.
We now have ClutterTouchpadPinchEvent and ClutterTouchpadSwipeEvent,
each bringing the necessary info for the specific gesture. Each
of these events is defined by begin/update/end/cancel phases.
These events have been also made to propagate down/up the pointer
position, just like scroll and button events do.
When binding models to actors to map items to children we don't often
need the full control of a function; in many cases we just need to
specify the type of the child we want to construct and the properties
on both the item and the child that we want to bind.
We should provide a simple convenience function that does all this for
us.
The whole of ClutterBackend is a final/protected type, so having a bunch
of instance fields and an instance private data structure is redundant
at best, and less efficient at worst.
GCC has some optimization for the inclusion guard, but they only work if
the check is the outermost one.
We're fairly inconsistent because of historical reasons, so we should
ensure that we follow the same pattern in every public header.
Use double precision floats for the intermediate computations, to avoid
loss of precision, and don't convert too integer when unnecessary, to
avoid rounding errors.
It can be useful to bind the children list to set of objects inside a
GListModel implementation; the GListModel stores the objects, and every
time the model changes, a function is called that maps each object in
the model to a newly created ClutterActor, which is then added as a
child. This API, along with the property binding one inside GObject,
allows automatic creation of views based on object models that update
themselves without manual intervention.
The model API was an ad hoc addition to Clutter, back in the 0.6 days,
that was needed because GLib did not offer anything of sort, and the
only model-like storage was inside GTK+. The API design was heavily
based on GtkTreeModel and friends, with column-based collections of
generic data.
Since then, the model API inside Clutter has not really been integrated
in the core API; on the other hand, GIO has grown a model API, and it's
seeing more use in the platform.
This means that the ClutterModel API should finally be deprecated, and
we should move code to the GListModel API inside GIO.
Like we do for X11, GDK, MacOS, and Windows, the Wayland backend can be
autodetected. We should only fail if the Wayland support was explicitly
asked at configure time, but the dependencies were not satisfied.
Certain crossing modes notify about synthesized events, where
the pointer didn't really leave the window. Unsetting the stage
from the device at that time is incorrect, and will leave all
remaining touches unable to pick coordinates, so silently eaten
away.
https://bugzilla.gnome.org/show_bug.cgi?id=750496
Straight from Cogl.
This allows us to propagate the GdkVisual Cogl and Clutter use to
embedding toolkits, like GTK+.
The function is annotated as being added to the 1.22 development
cycle because it will be backported to the stable branch, so that
downstream developers can package up a version of Clutter that does
not crash on nVidia.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
GDK 3.16 started selecting different visuals, to best comply with the
requirements for OpenGL, and this has broken Clutter on GLX drivers that
are fairly picky in how they select visuals and GLXFBConfig.
GDK selects GLXFBConfig that do not include depth or stencil buffers;
Cogl, on the other hand, needs both depth and stencil buffers, and keeps
selecting the first available visual, assuming that the GLX driver will
give us the best compliant one, as per specification. Sadly, some
drivers will return incompatible configurations, and then bomb out when
you try to embed Clutter inside GTK+, because of mismatched visuals.
Cogl has an old, deprecated, Clutter-only API that allows us to retrieve
the XVisualInfo mapping to the GLXFBConfig it uses; this means we should
look up the GdkVisual for it when creating our own GdkWindows, instead
of relying on the RGBA and system GdkVisuals exposed by GDK — at least
on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
