The ClutterX11XInputEventTypes enumeration has been unused inside
Clutter for the past 4 years and a half, since we switched to the
XInput 2 API.
The enumeration itself has always been private, and nobody should
have used it in the first place, but if something breaks, we can
revert this commit.
They should be part of the backend-specific API.
The only backend that has an enumeration type is the X11 one, and it's
small, so we can simply put it there.
This is not an ABI change: the backend-specific symbols are still in
the same SO. You'll be required to import clutter-x11.h to have access
to the GType method at the source level, whereas before just importing
clutter.h would have sufficed. The only user of that enumeration was a
function declared in clutter-x11.h, anyway.
We're inconsistently using the NAMESPACE variable instead of passing
the --identifier-prefix and --symbol-prefix command line arguments to
the introspection scanner.
Now that we can warn about deprecated macros, we should finally do it
for the old, non-namespaced key symbol macros that we've been stringing
along since the 1.0 days.
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.
