Until now, touch events sort of rely on XI_Enter/XI_Leave events accompanying
the pointer emulating touch in order to have a stage set on the device, These
events won't happen though if it's not a pointer emulating touch which happens
on the stage, causing touch events to be ignored.
Fix this by ensuring that the input device has a stage on XI_TouchBegin itself,
but only if it's not already set, so we don't possibly steal touch events to
an already interacting stage.
https://bugzilla.gnome.org/show_bug.cgi?id=732234
On X11 the pointer will follow a "pointer emulating" touch sequence, so the
pointer will be effectively left inside the stage after that touch is lifted,
even though the master device stage is unset. This makes pointer events get
ignored until the pointer leaves and enters again the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=732234
The 'state' field should be used for pointer events without button
information. Pointer events that have button information should use
the 'button' field.
https://bugzilla.gnome.org/show_bug.cgi?id=732143
The coordinates translated by the XI2 device manager were being clamped using
the X window size kept by StageX11. However, when the stage is fullscreen,
that size is not updated to the screen size, but kept the same in order to
allow going back to it when the stage goes out of fullscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=731268
The vector of libinput and Wayland pointer axis events are in pointer
motion coordinate space. To convert to clutter's internal representation
the vectors need to be scaled to Xi2 scroll steps.
https://bugzilla.gnome.org/show_bug.cgi?id=723560
And get CLUTTER_EVENT_LEAVE out of the touch event compression logic, as
touches are always implicitly grabbed. If no sequence check is done, only
the last touch update would be emitted, even if multiple sequences got
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=730577
Let's cross fingers and hope nobody notices. If this went unnoticed so far, likely
means this function has never been used. If any complain is raised about this, a
stub function should be added (and marked deprecated).
Those are translated into CLUTTER_TOUCH_* ClutterEvents. As the
"NULL" ClutterEventSequence is special cased, the slot=0 value is
avoided.
Frame events are ignored, as there is no Clutter equivalence, and
Cancel events are sent to all current individual touches.
https://bugzilla.gnome.org/show_bug.cgi?id=728968
And ensure the core pointer shares the same stage than the slave
device when those events are set. This fixes problems on the evdev
backend where the last touch unsets the stage on the device, but
nothing sets it back afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=728968
When an actor carrying canvas content is repainted, it will currently reupload
the data from the buffer to a texture. While this is not a performance problem
on a desktop, some mobile environments take a big performance hit. This
change tracks data changes and only recreates the texture if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=729144
By creating and starting the timer on clutter_main() an assumption is made
that that is how the main loop will be run for all clutter applications.
With more and more applications moving to GApplication, this assumption no
longer holds true.
Moving to clutter_init() means we are starting the timer earlier than we
should, and by not stopping it when the main loop quits we are taking a
measure that is later than we should. I believe it is safe to consider
those are close enough to the actual beginning and quitting of the main
loop in practice.
https://bugzilla.gnome.org/show_bug.cgi?id=728521
Instead of just bailing out when initializing the test suite, we can do
a much better job and skip all the tests. This means that the TAP driver
will work correctly instead of dying a horrible death, and we get a nice
report with a proper cause of the test skipping.
Without a paint() implementation in clutter-stage, the function
from clutter-group is used. That class has its own child list,
but attempts to use sort_depth_order, which is empty in this case.
This provides a partial fix by replacing a minimal paint(), see:
https://bugzilla.gnome.org/show_bug.cgi?id=711645
Commit e70a0109 simplified the dispatching of events by passing the event's
owernership to ClutterStage, but it may be so that any.stage is NULL at
some point on Windows, which will either cause _clutter_stage_queue_event()
to crash or issue a critical warning. Avoid this problem by checking
whether event->any.stage is not NULL before trying to call
_clutter_stage_queue_event().
https://bugzilla.gnome.org/show_bug.cgi?id=726765
...so that its entries will reflect the entries that are checked by the
autotools builds on config.h.in. Also take into consideration for MinGW
builds and for newer Visual Studio versions, such as the availability for
inttypes.h. Update the layout of the file cosmetic-wise as well.
Clutter, like GTK+ and GLib, has recently switched to a visibility-based
method of exporting symbols, so update the Visual Studio build files to
do likewise, by using __declspec (dllexport). This eliminats the need to
use a .def file to export the symbols. The pre-configured
config.h.win32.in is also updated accordingly for this purpose. The
clutter.symbols file can be dropped if it is not being used otherwise.
Instead of listing every public symbol inside an ancillary file, we can
use compiler annotations. This scheme is also used by GLib and GTK+.
The symbols file is left in tree until the Visual Studio rules are
fixed, but it's not used any more during distcheck.
I double-checked that the exposed ABI is the same before and after this
change, except for symbols that were never meant to be public in the
first place, and that escaped our attention when we generated the first
version of the symbols file.
All backends follow the same pattern of queueing events first in
ClutterMainContext, then copying them to a ClutterStage queue and
immediately free them. Instead, we can just pass ownership of events
directly to ClutterStage thus avoiding the allocation and copy in
between.
https://bugzilla.gnome.org/show_bug.cgi?id=711857
Keep track of the button modifier mask state in
ClutterInputDeviceWayland and push its state to new button events going
out.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=708781
We do not strictly require the 'swap-region' Cogl feature in order to use
clipped redraws: they work equally well with just the 'buffer-age' Cogl
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=726313
_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
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
Currently we where checking whether the damage_history list contains
more or equal then buffer_age entries. This is wrong because we prepend
our current clip to the list just before the check.
Fix that to check whether we have more entries instead of more or equal.
https://bugzilla.gnome.org/show_bug.cgi?id=724788
The documentation for the s and l components is incorrect; these have to
be percentage values and must have a '%' character right after the
number.
Based on a patch by: Pablo Pissanetzky <pablo@trickplay.com>
https://bugzilla.gnome.org/show_bug.cgi?id=662818
The internal delete_text() implementation takes a start and an end
position, whereas the public delete_chars() method takes a number of
characters to delete starting from the current cursor position.
The :unscaled-font-dpi property is used to override the existing
:font-dpi value when running on high DPI density displays; since it's a
write-only property we don't need to have a separate storage, nor we
need to choose between :font-dpi and :unscaled-font-dpi depending on
whether or not either has been set. If we select which one to use
between :font-dpi and :unscaled-font-dpi when computing the font
resolution, we end up breaking the code that relies on changing
:font-dpi directly on a per-Settings basis.
Like we do for the windowing surfaces, we should have a run time knob
(in the form of an environment variable) to allow changing the scaling
factor of the font resolution.
We need to provide an escape hatch to ClutterCanvas so that it's
possible to override the window-scaling-factor ClutterSetting. This is
going to be useful in the future in case the user has better knowledge
of the window scaling factor that is going to be used with a specific
set of ClutterCanvas contents (e.g. on different outputs or stages).
https://bugzilla.gnome.org/show_bug.cgi?id=705915
ClutterCanvas is a ClutterContent interface implementation; this means
that it can be created and modified regardless of whether it is
associated to a specific actor or a stage. For this reason, we cannot
walk the hierarchy and get the window scaling factor for high DPI
density displays out of the ClutterStage when we create the Cairo
surface that we will use to draw the canvas contents on.
We can use ClutterSettings:window-scaling-factor instead, since it's
what each ClutterStage will use anyway.
This will get slightly more complicated when we support per-output
window scaling factors (like on Wayland), but that will require changes
in the entire settings architecture anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
If we get a change in the window scaling factor we want to resize the
backing store of each stage, so we use the notification on the
ClutterSettings:window-scaling-factor property to do so.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
