Those can be used to implement different scrolling behaviors.
The fields have been added to ClutterScrollEvent itself. According
to pahole, this makes the struct as big as ClutterButtonEvent and
ClutterTouchEvent, so already at the limit of the ClutterEvent
union.
https://bugzilla.gnome.org/show_bug.cgi?id=757026
So that we can set it to 'check', and do configure-time discovery of the
dependencies, instead of enabling it explicitly.
This should make it easier to spot build issues on environments like
Continuous, which build Clutter and Cogl for running as part of the
display server infrastructure on Wayland.
We should allow a configuration file to set up the initial state of the
global state, which also implies being able to set the backend.
If the allowed backends have already been set programmatically via the
clutter_set_windowing_backend(), though, then the application code takes
precedence, as we assume that the application author knows better than
us what their code supports or requires.
The configuration file should set up the global state before we
initialize it; instead of relying on implicit ordering, explicitly read
the configuration file once, when creating the global shared context
data structure.
Like CLUTTER_DRIVER, we want to allow users to specify a list of
backends to test, and fall back to the internally defined priority as a
default.
This requires changing the way the allowed backend string is parsed,
both for the CLUTTER_BACKEND environment variable and for the
clutter_set_windowing_backend() function. Existing callers are still
supported with the exact same semantics.
Using environment variables only is not convenient for all platforms,
and in some cases it's beneficial to decide the default driver when
building Clutter. Cogl already has a similar configuration switch, and
since Clutter is overriding the default Cogl behaviour, it should offer
the same mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=742678
We have an hardcoded list of drivers we have to go through when creating
a Cogl context. Some platforms may expose those drivers, but not be the
preferred ones.
In order to allow users and system integrators to override the list of
drivers, we should crib the same approach used by GDK, and have an
environment variable with a list of drivers to try.
The new environment variable is called `CLUTTER_DRIVER` and accepts a
comma-separated list of driver names, which will be tested in sequence
until one succeeds. There's also an additional '*' token which is used
to ask Clutter to fall back to the internally defined preferred list of
drivers.
https://bugzilla.gnome.org/show_bug.cgi?id=742678
We enable a bunch of compiler flags to trip common errors during
development. While this is very useful while hacking on Clutter, it
makes the life of people building Clutter on automated build systems
much harder; thus, we should have a configuration option to opt out of
the -Werror business.
GNOME has pretty much standardised on `--disable-Werror`, so we should
crib that configure option.
Being able to select text and being able to edit text are two separate
capabilities, but ClutterText only allows the former with the latter.
The ClutterText:selectable property is set to TRUE by default, given
that it depends on the :editable property; this implies that all
ClutterText instances now are going to show a cursor as soon as they get
key focused. Obviously, this would make labels look a bit off — but if
you have a label then you would not give it key focus, either by
explicitly calling clutter_actor_grab_focus(), or by setting it as
reactive and allowing it to be clicked.
If this turns out to be a problem, we have various ways to avoid showing
a cursor — for instance, we could change the default value of the
selectable property, and ensure that setting the :editable property to
TRUE would also set the :selectable property as a side effect. Or we
could hide the cursor until the first button/touch press event. Finally,
we could always back this commit out if it proves to be too much of a
breakage for existing code bases.
https://bugzilla.gnome.org/show_bug.cgi?id=757470
The X11 part of the GDK backend takes into account the scaling factor of its
window when resizing the underlying X11 objects. We need to do the same for
Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=755245
This is now stored as platform data in the ClutterEvent, so can
be retrieved with the clutter_evdev_event_get_event_code() call
that's been added to the evdev backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
Device managers can now implement the ClutterEventExtender interface
that allows them to set their own data to events, make the backend call
those implementations if the device manager implements the interface.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
This normally belonged to the ClutterBackend, however there's device
managers (eg. evdev) that are somewhat detached from the backend, so
need to bridge this somehow.
This allows device managers to implement these bits that were usually
responsibility of the ClutterBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
On X11 those were skipped, so additional pointer buttons would come up
as button >= 8 events. Do here the same, so we remain compatible across
backends.
https://bugzilla.gnome.org/show_bug.cgi?id=758237
