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
We want the settings object to handle setting and getting the
window scaling factor value, both through backend-specific settings and
through the CLUTTER_SCALE environment variable. This means turning the
ClutterSettings:window-scaling-factor property into a readwrite one,
instead of write-only, so that ClutterStage implementations will be able
to query the window scaling factor on construction.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
We do some argument validation inside _clutter_stage_do_pick(), which is
the internal version of clutter_stage_get_actor_at_pos(), but we don't
do coordinate space validation, and instead we rely on call sites doing
the right thing.
We should, instead, remove the argument validation from the internal
function, which is pointless and against the coding practices, but do
coordinate space validation internally.
https://bugzilla.gnome.org/show_bug.cgi?id=722322
The current conformance test suite is suboptimal in many ways.
All tests are built into the same binary, which makes adding new tests,
builting tests, and running groups of tests much more awkward than it
needs to be. The first issue, especially, raises the bar of contribution
in a significant way, while the other two take their toll on the
maintainer. All of these changes were introduced back when we had both
Clutter and Cogl tests in tree, and because we were building the test
suite for every single change; since then, Cogl moved out of tree with
all its tests, and we build the conformance test suite only when running
the `check` make target.
This admittedly large-ish commit changes the way the conformance test
suite works, taking advantage of the changes in the GTest API and test
harness.
First of all, all tests are now built separately, using their own test
suite as defined by each separate file. All tests run under the TAP
harness provided by GTest and Automake, to gather a proper report using
the Test Anything Protocol without using the `gtester` harness and the
`gtester-report` script. We also use the Makefile rules provided by GLib
to vastly simplify the build environment for the conformance test suite.
On top of the changes for the build and harness, we also provide new API
for creating and running test suites for Clutter. The API is public,
because the test suite has to use it, but it's minimal and mostly
provides convenience wrappers around GTest that make writing test units
for Clutter easier.
This commit disables all tests in the conformance test suite, as well as
moving the data files outside of the tests/data directory; the next few
commits will re-establish the conformance test suite separately so we
can check that everything works in a reliable way.
When the threshold-trigger-edge property was introduced in
GestureAction, it was late in the cycle and I elected to keep it
private, given the fact that nobody was subclassing GestureAction
outside of Clutter itself.
These days, people are experimenting more with the GestureAction API, so
they will need access to the various knobs that control the class
default behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=710227
Use G_GNUC_INTERNAL instead of the leading underscore, as we may make
the accessor functions public at some point. Also, clean up the
documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=710227
Our clip coordinates are relative to the stage, not model-view
transformed. cogl_framebuffer_push_rectangle_clip() was accidentally
used instead of cogl_framebuffer_push_scissor_clip() when porting
to the framebuffer clip API.
https://bugzilla.gnome.org/show_bug.cgi?id=719900
Currently, if an actor with an empty paint volume is queued for redraw, it
will union in the box +0+0x1x1 to the stage clip bounds - avoid that
by special casing empty paint volumes.
https://bugzilla.gnome.org/show_bug.cgi?id=719747
The PaintNode hierarchy should have the ability to retrieve the
current active framebuffer by itself, instead of asking Cogl using the
global state API.
In order to do this, we ask the root node of a PaintNode graph for the
active framebuffer. In the current, 1.x-compatibility mode we have two
potential root node types: ClutterRootNode, used by ClutterStage; and
ClutterDummyNode, used a local root for each actor. The former takes a
framebuffer as part of its construction; the latter takes the actor that
acts as the local top-level during the actor's paint sequence, which
means we can get the active framebuffer from the stage associated to the
actor.
By keeping track of the active framebuffer on the node themselves we can
drop the usage of cogl_get_draw_framebuffer() in their implementation.
The text-cache conformance test breaks because ClutterText gets a paint
without an active framebuffer associated to the ClutterStage. Keep a
fallback while we investigate the issue.
Cogl 1.18 deprecated the global clipping API in favour of the
per-framebuffer one, but since we're using the 2.0 API internally we
don't have access to the deprecated symbols any more.
This is pretty much a mechanical port for all the places where we're
still using the old 1.x API.
Instead of asking every internal user to get the stage and get the
active framebuffer from it, we can wrap it up ourselves, and do some
sanity checks as well.
Dispose() may be called more than once, so calling g_free directly
on the device name is unsafe. Instead, use g_clear_pointer() to
make sure we don't attempt to free the memory again.
https://bugzilla.gnome.org/show_bug.cgi?id=719563
When support for implicit animation of actor position was added,
the optimization for not queueing when allocating an actor back
to the same location was lost. This optimization is important
since when we are hierarchically allocating down from the top of
the stage we constantly reallocate the actors at the top of the
hierarchy back to the same place.
https://bugzilla.gnome.org/show_bug.cgi?id=719368
When the source actor potentially changes size, that shouldn't
necessarily result in the target actor being redrawn - it should
be like when a child of a container is reallocated due to changes
in its siblings or parent - it should redraw only to the extent
that it is moved and resized. Privately export an internal function
from clutter-actor.c to allow getting this right.
https://bugzilla.gnome.org/show_bug.cgi?id=719367
Since the journal is flushed on context switches, trying to use a cached
buffer means that we will use glReadPixels when picking, which isn't what
we want. Instead, always use a clipped draw, and remove the logic for
caching the pick buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=712563
The table layout manager has various issues:
• no support for RTL flipping
• most of the layout API is legacy, and has been replaced by the
alignment and expansion flags on ClutterActor
• the animation API is legacy, and has been replaced by the
implicitly animatable allocation
• the spanning cells handling is a bit awkward, as is its API
On top of that, we imported the grid layout management policy from GTK+
into ClutterGridLayout, which provides all the required features in a
more well-designed API.
Instead of wasting time and resources updating TableLayout, we should
deprecate it and point developers of the GridLayout.
This adds clutter_event_add/remove_filter which adds a callback
function which will receive all Clutter events just before the event
signal is emitted for them. The event filter will be invoked
regardless of any grabs or captures. This will be used by Mutter which
wants to access the events at a lower level then the event bubbling
mechanism. It needs to see all mouse motion events even if there is a
grab in place.
https://bugzilla.gnome.org/show_bug.cgi?id=707560
The state that the X server sends for button events, by specification,
contains the button state before the event. We need to synthesize in
the result of the event in order to determine what the current button
state is.
https://bugzilla.gnome.org/show_bug.cgi?id=712322
XFixesShowCursor / XFixesHideCursor does not actually take the suppled
window argument into account -- the effect is actually global. Use
XDefineCursor instead.
https://bugzilla.gnome.org/show_bug.cgi?id=707071
Destroying an actor is supposed to destroy all of its children, so
it makes sense to reason that destroying the stage should destroy all
of its children, too.
Unfortunately, it seems that the stage removed all of its children
without destroying them before chaining up to what would destroy all
of its children, for whatever reason. Change this to a destroy so
resources get cleaned up.
The TextureNode premultiplies the blend color passed to the node
constructor, so we need to document the fact properly to avoid
causing premultiplication twice.
We can also allow passing NULL for a color, and use a fully opaque
white, to make the code slightly more friendly.
ClutterTextureNode will do that for us when converting the ClutterColor
to a CoglColor, so we can simply pass a white color with the correct
alpha channel.
The calculation (n - 1) * spacing to compute the total spacing is
only correct for n >= 1 - if there are no visible rows/cols, the
required spacing is 0 rather than negative.
https://bugzilla.gnome.org/show_bug.cgi?id=709434
For some XI2 we do not have a Stage associated to the event window.
Original patch by: Giovanni Campagna <scampa.giovanni@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=708439
On high DPI density displays we create surfaces with a size scaled up by
a certain factor. Even if the contents stay at the same relative size
and position, we need to compensate the scaling both when changing the
surface size, and when dealing with input.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
In order to transparently support high DPI density displays, we must
maintain all coordinates and sizes exactly as they are now — but draw
them on a surface that is scaled up by a certain factor. In order to
do that we have to change the viewport and initial transformation
matrix so that they are scaled up by the same factor.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
The added support is very very basic (single touch, motion only,
no acceleration, no pressure recognition), but anything more
complex requires a state machine that will be hopefully provided
by libinputcommon in the future.
And at least, with this patch the pointer moves, which will be
useful for people testing wayland in 3.10 without a physical mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
