_clutter_stage_window_can_clip_redraws is used to check for clipped redraws
support but can_clip_redraws is not implemented by clutter-stage-wayland so
it always returns FALSE causing full screen redraws.
Fix that by implementing can_clip_redraws in clutter-stage-wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=726315
There could be times when we may not necessarily see a device appear
at initialization time, like when we're VT switched away when we
initialize, and thus we can't ever rely on a main seat appearing.
Always create a main seat with logical pointer/keyboard devices, and
tie the first physical seat that comes in to the main seat.
https://bugzilla.gnome.org/show_bug.cgi?id=726199
We're going to create the main seat at an earlier time, when
we don't have the physical libinput_seat yet, so we need to
do the association later.
https://bugzilla.gnome.org/show_bug.cgi?id=726199
The GetSystemMetrics() function returns wrong values for SM_CXSIZEFRAME,
SM_CYSIZEFRAME, SM_CXFIXEDFRAME and SM_CYFIXEDFRAME when built with Visual
Studio 2012 and 2013 (unless the XP compatibility setting for the
PlatformToolset entry is turned on), causing the window of Clutter programs
to automatically shrink to a point where they become unusable.
This patch uses AdjustWindowRectEx() for builds using Visual Studio 2012
and later, which deduces the required height and width of the Window
properly. Unfortunately we can't use this for the VS 2008/2010 builds as
they cause the Window to continually expand as the program is run.
https://bugzilla.gnome.org/show_bug.cgi?id=725873
The GetSystemMetrics() function returns wrong values for SM_CXSIZEFRAME,
SM_CYSIZEFRAME, SM_CXFIXEDFRAME and SM_CYFIXEDFRAME when built with Visual
Studio 2012 and 2013 (unless the XP compatibility setting for the
PlatformToolset entry is turned on), causing the window of Clutter programs
to automatically shrink to a point where they become unusable.
This patch uses AdjustWindowRectEx() for builds using Visual Studio 2012
and later, which deduces the required height and width of the Window
properly. Unfortunately we can't use this for the VS 2008/2010 builds as
they cause the Window to continually expand as the program is run.
https://bugzilla.gnome.org/show_bug.cgi?id=725873
This adds a PlatformToolset tag for each configuration so that it is easier
to upgrade the projects to Visual Studio 2012/2013 formats, which are
largely the same as the Visual Studio 2010 projects. We can, for example,
use a script to change the values of the PlatformToolset to make these
projects usable out-of-the-box for Visual Studio 2012/2013.
Like the Visual Studio 2008 projects, give the Visual Studio 2010 projects
an overhaul, where:
-The property sheets are split up, so that they are easier to maintain and
each project only needs to include the necessary parts. The various
projects are updated accordingly, too. The copying of config.h.win32 and
clutter-config.h.win32(_GDK) are now done with custom build rules, so that
these files can be cleaned and/or recopied during a clean, rebuild or
update.
-Clean up the property sheets, to get rid of parts that are actually
repeated. Also update the build macros, so that we won't get warnings
for repeated #defines of macros and fix the build of the various tests/
demo programs.
-Make all projects use Unix line endings, except for the .sln and
README.txt files, which need to have Windows line endings. This makes it
easier to apply patches to these project files.
-Update the installation of headers, as headers are introduced/deprecated.
-Cosmetics: get rid of "\ No newline at end of file".
Split up the property sheets, so that they are easier to maintain, and
clean up the projects and property sheets, especially on items that are
being repeated, and therefore silence many build warnings. Update the
project files correspondingly, and make all project files use Unix line
endings, for easier application of patches (the .sln and README.txt files
still has to have Windows line endings in order to work properly).
Also make the copying of config.h.win32 and clutter-config.h.win32(_GDK)
custom build rules, so that they may also be cleaned during the cleaning
of the build, which makes it easier for one to do a rebuild.
Similar updates to the Visual Studio 2010 project files will follow.
We should use the Xkb API to query the direction of the key map,
depending on the group. To get a valid result we need to go over
the Unicode equivalents of the key symbols for each group, so we
should cache the result.
The code used to query and cache the key map direction is taken
from GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=705779
We should set the direction on the PangoContext when creating a
PangoLayout based on a best effort between the contents of the text
itself and the text direction of the widget, in case that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=705779
Currently clutter_device_manager_xi2_get_core_device always
does a round trip to query the client.
So avoid that by caching the client pointer and only update it when the
xi devices change.
https://bugzilla.gnome.org/show_bug.cgi?id=725561
ClutterInputDevice's default initial coordinates is (-1, -1) and since
they're updated from events in a relative way it means that the
pointer can go outside the stage right from the first event.
We usually let this up to higher layers to fix through the pointer
constraint callback but that doesn't work if the first event doesn't
put the pointer immediately inside the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=725103
Doing so is unlikely to work reliably. Instead, switching the keymap
should be done at a time when no key is currently pressed down, but
let's leave that task to higher level code.
This allows us to remove key state tracking at yet another level in
the stack since higher level code likely already tracks this for other
purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=725102
The kernel keyboard repeat functionality isn't configurable and
libinput rightfully ignores it.
This implements keyboard repeat in userspace allowing for consumers to
set the initial delay and repeat intervals.
https://bugzilla.gnome.org/show_bug.cgi?id=725102
The evdev backend has always been excluded from Clutter's API
stability guarantee though in an informal way. This commit makes it
explicit by forcing users to define CLUTTER_ENABLE_COMPOSITOR_API.
https://bugzilla.gnome.org/show_bug.cgi?id=725102
Instead of having its own evdev input device processing implementation,
make clutter's evdev backend use libinput to do input device processing
for it.
Two GObject parameters of ClutterInputDeviceEvdev (sysfs-path and
device-path) are removed as they are not used any more.
Before ClutterDeviceManagerEvdev had one virtual core keyboard and one
virtual core pointer device. These are now instead separated into seats,
which all have one virtual core keyboard and pointer device respectively.
The 'global' core keyboard and pointer device are the core keyboard and
pointer device of the first seat that is created.
A ClutterInputDeviceEvdev can, as before, both represent a real physical
device or a virtual device, but is now instead created either via
_clutter_input_device_evdev_new() for real devices, and
_clutter_input_device_new_virtual() for virtual devices.
XKB state and button state is moved to the seat structure and is thus
separated per seat. Seats are not a concept exposed outside of clutter's
evdev backend.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=720566
Due to the way add_device() invariably adds to the master/slave device
lists, while keeping ClutterInputDevices 1:1 with device IDs, it may
leave invalid pointers in the list if add_device() is called multiple
times for the same device ID. There are two situations where this may
happen:
1) If devices are disabled and later enabled: devices are added invariably
to the master/slave lists on constructed(), but then on XIDeviceEnabled
they'd get added yet again.
2) Racy cases where the ClutterDeviceManager is created around the same time
XIHierarchyEvents are sent. When getting the XIDeviceInfo on constructed(),
these devices may already appear as enabled, even though XIDeviceEnabled
is seen through XIHierarchyEvents processed in the event loop sortly after.
This last case can be seen when starting gnome-shell on a different tty,
and entering in the one it's been spawned on, clutter initialization
happens around the same time devices are added back because of the tty
switch, and multiple extra ClutterInputDevices are created.
https://bugzilla.gnome.org/show_bug.cgi?id=724971
Due to the way add_device() invariably adds to the master/slave device
lists, while keeping ClutterInputDevices 1:1 with device IDs, it may
leave invalid pointers in the list if add_device() is called multiple
times for the same device ID. There are two situations where this may
happen:
1) If devices are disabled and later enabled: devices are added invariably
to the master/slave lists on constructed(), but then on XIDeviceEnabled
they'd get added yet again.
2) Racy cases where the ClutterDeviceManager is created around the same time
XIHierarchyEvents are sent. When getting the XIDeviceInfo on constructed(),
these devices may already appear as enabled, even though XIDeviceEnabled
is seen through XIHierarchyEvents processed in the event loop sortly after.
This last case can be seen when starting gnome-shell on a different tty,
and entering in the one it's been spawned on, clutter initialization
happens around the same time devices are added back because of the tty
switch, and multiple extra ClutterInputDevices are created.
https://bugzilla.gnome.org/show_bug.cgi?id=724971
