The type has been deprecated, so stop using it. The easiest replacement
would be to add our own struct, but considering that separate name/value
arrays are easier to free (g_auto!) and we already do the split in one
place, go that route.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Currently nothing in the clutter machinery prevents hidden portions
of the actor tree from calling queue_relayout() (and having it fully
honored).
But that allocation should not be necessary till the actor is shown,
and one of the things we do on show() is queueing a relayout/redraw
after flagging the actor as visible.
We can simply defer clutter_actor_allocate() calls till that show()
call, and leave the needs_allocate and other flags set so we ensure
the allocation is properly set then.
This should cut down some needless operations when invisible portions
of the actor tree change indirectly due to user interaction, or due
to background activity.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/677
Clutter has two motion event toggles: one in the global context, and
one per stage. The global one is deprecated, and currently unused.
Remove the global motion event handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/666
The “togglekeys” setting is to emit a sounds whenever the state of one
of the modifiers keys (CAPS lock, NUM Lock, SCROLL lock) is changed, it
has nothing to do with the rest of the accessibility settings.
Therefore, there is no need to reset the various timers used by
accessibility whenever the “togglekeys” setting is changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/614
ClutterStage:after-paint now does not guarantee a valid
implicit framebuffer pushed to the stack. Instead, use
the new 'paint-view' signal, that is emitted at a point
in the drawing routine where a framebuffer is pushed.
In addition to that, stop using the implicit framebuffer
API and port the actor-shader-effect test to read from
the view's framebuffer directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
Now that ClutterStageView is embraced as part of the public
set of Clutter classes, is it possible to give consumers
of this API more information and control over the drawing
routines of ClutterStage.
Introduce ClutterStage:paint-view, a signal that is emitted
for painting a specific view. It's defined as a RUN_LAST
signal to give anyone connecting to it the ability to run
before the view is actually painted, or after (using the
G_CONNECT_AFTER flag, or g_signal_connect_after).
This signal has a corresponding class handler, which allows
Mutter to have much finer control over the painting routines.
In fact, this will allow us to implement a "paint phase watcher"
mechanism in the following patches.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
ClutterStage:after-paint is supposed to be emitted after all
painting is done, but before the frame is finished. However,
as it is right now, it is being emitted after each view is
painted -- on multi-monitor setups, after-frame is being
emitted multiple times.
Send after-paint only once, after all views are painted and
before finishing the frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
As a compositor toolkit, it makes sense to allow consumers
of Clutter interact with the stage views themselves. As such,
ClutterStageView should be a public class.
As such, it is now included in clutter.h and should not be
included directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
When libwacom is configured disabled, this error appears:
../clutter/clutter/x11/clutter-input-device-xi2.c: In function ‘clutter_input_device_xi2_finalize’:
../clutter/clutter/x11/clutter-input-device-xi2.c:122:7: error: ‘device_xi2’ undeclared (first use in this function)
if (device_xi2->inhibit_pointer_query_timer)
Fix it with the "obvious" solution.
This code was added in c1303bd642.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/611
When a user moves their cursor the perceived behaviour is that it will
pick what is under the cursor. However this isn't how picking works.
Picking does a virtual redraw of the screen, so in some cases what gets
picked isn't the same as what the user could see on the previous frame.
It more represents what will be drawn on the next frame than what is on
screen at present.
It may be unsafe to change these semantics, and they are useful anyway.
Just document it better.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/214
After 4faeb12731, the maximum time allowed for an update to happen
is calculated as:
max_render_time_allowed = refresh_interval - 1000 * sync_delay;
However, extremely small refresh intervals -- that come as consequence
to extremely high refresh rates -- may fall into an odd numerical range
when refresh_interval < 1000 * sync_delay. That would give us a negative
time.
To be extra cautious about it, add another sanity check for this case.
Change suggested by Jasper St. Pierre.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
The presentation timing logic (via `master_clock_get_swap_wait_time`) now
works unconditionally. By "works" we mean that a result of zero from
`master_clock_get_swap_wait_time` actually means zero now. Previously
zero could mean either a successful result of zero milliseconds or that
the backend couldn't get an answer. And a non-zero result is the same as
before.
This works even if the screen is "idle" and even if the backend doesn't
provide presentation timestamps. So now our two fallback throttling
mechanisms of relying on `CLUTTER_FEATURE_SWAP_THROTTLE` and decimating
to `clutter_get_default_frame_rate` can be deleted.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/406 and
https://bugzilla.gnome.org/show_bug.cgi?id=781835https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
If `last_presentation_time` is zero (unsupported) or just very old
(system was idle) then we would like to avoid that triggering a large
number of loop interations. This will get us closer to the right answer
without iterating.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
That could happen if the backend did not provide presentation timestamps,
or if the screen was not changing other than the hardware cursor:
if (stage_cogl->last_presentation_time == 0||
stage_cogl->last_presentation_time < now - 150000)
{
stage_cogl->update_time = now;
return;
}
By setting `update_time` to `now`, master_clock_get_swap_wait_time()
returns 0:
gint64 now = g_source_get_time (master_clock->source);
if (min_update_time < now)
{
return 0;
}
else
{
gint64 delay_us = min_update_time - now;
return (delay_us + 999) / 1000;
}
However, zero is a value unsupported by the default master clock
due to:
if (swap_delay != 0)
return swap_delay;
All cases are now handled by extrapolating when the next presentation
time would be and calculating an appropriate update time to meet that.
We also need to add a check for `update_time == last_update_time`, which
is a situation that just became possible since we support old (or zero)
values of `last_presentation_time`. This avoids getting more than one
stage update per frame interval when input events arrive without
triggering a stage redraw (e.g. moving the hardware cursor).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
Instead of crazy refresh rates >1MHz falling back to 60Hz, just honour
them by rendering unthrottled (same as `sync_delay < 0`). Although I
wouldn't actually expect that path to ever be needed in reality, it just
ensures an infinite `while` loop never happens.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
When using evdev (for Wayland), the backend receives all device events
and queue them for clutter.
Hook up the pointer accessibility handlers in clutter's main processing
queue, so that we get better accuracy for pointer location.
We need to avoid doing this on X11 though because X11 relies on the raw
events for this to work reliably, so the same is already done in the
X11 backend when using X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Pointer accessibility features requires to receive all pointer events
regardless of X11 grabs.
Add XI2 raw events mask and hook up the pointer accessibility handlers
to the raw motion and button press/release events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Add support for click assist, namely simulated secondary click (on a
long primary button press) and hover click support (simulate a click when
the pointer remains static for some time).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Add the required signaling in place in clutter device manager to notify
the upper layers (namely, the shell) whenever a click assist delay or
gesture is started or stopped.
This will allow the shell to implement a visual feedback for click
assist operations.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
For accessibility features, being either keyboard accessibility to
implement mousekeys, or pointer accessibility to implement simulated
secondary click or dwell click, we need to have a virtual device.
Add that virtual device in ClutterInputDevice so it can be used either
for keyboard or pointer accessibility.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Certain arguments like `-fno-omit-frame-pointer` break GIR creation.
Lets handle this like we do for the rest of mutter and duplicate the
relevant arguments from `clutter_c_args`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/601
Spotted while adding tracing to swap buffers, we only enter
the first part of the if condition when use_clipped_redraw
is TRUE, so it's pretty safe to assume it's TRUE.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
The idea here is to be able to visualize and immediately
understand what is happening. Something like:
```
[ view1 ] [ view2 ]
[---- Layout ---][------ Paint ------][ Pick ]
[================== Update =====================]
```
But with colors. A few of the previous profiling data
sections were removed, since they didn't really add to
reading the graph.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add debug flags based on meson's `debug` option instead of `buildtype`.
This allows custom build configurations to behave like a debug or release build.
Add `-fno-omit-frame-pointer` to Mutter/Cogl. Not to Clutter though, as that would
require more changes to how Clutter's gir is created
Remove `-DG_DISABLE_CAST_CHECKS` from Clutter in debug builds
Add `-DG_DISABLE_CHECKS`, `-DG_DISABLE_ASSERT` and `-DG_DISABLE_CAST_CHECKS` to all
non-debug builds but `plain`, which explicitly should not have any compile flags
Use `cc.get_supported_arguments`, so it becomes more obvious to the user which flags
are set during compilation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/497
Commit df7d8e2cb highlights a crash on test_destroy_destroy, in fact it could
happen that calling clutter_actor_destroy on a child while iterating on the
list, would implicitly call test_destroy_remove that tries to modify the list
at the same time. Causing a memory error.
So instead of manually free the children list, just ensure that this list is
valid and that when the object destruction is done, this is free'd.
See: https://gitlab.gnome.org/GNOME/mutter/merge_requests/576https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Commit cabcad185 removed the call to cogl_set_source_color4ub() before
cogl_fill_path(), so instead of the previously assigned selection color,
the background is drawn with the last set source.
In order to honour the newly added framebuffer parameter and still apply
the correct color, switch from cogl_fill_path() to the (deprecated!)
cogl_framebuffer_fill_path() method.
https://gitlab.gnome.org/GNOME/mutter/issues/494
If an update (new frame) had been scheduled already before
`_clutter_stage_cogl_presented` was called then that means it was
scheduled for the wrong time. Because the `last_presentation_time` has
changed since then. And using an `update_time` based on an outdated
presentation time results in scheduling frames too early, filling the
buffer queue (triple buffering or worse) and high visual latency.
So if we do receive a presentation event when an update is already
scheduled, remember to reschedule the update based on the newer
`last_presentation_time`. This way we avoid overfilling the buffer queue
and limit ourselves to double buffering for less visible lag.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/334
Prerequisite: https://gitlab.gnome.org/GNOME/mutter/merge_requests/520https://gitlab.gnome.org/GNOME/mutter/merge_requests/281
Pango functions pango_unichar_direction() and pango_find_base_dir() have been
deprecated in pango 1.44, since these are used mostly clutter and gtk, copy the
code from pango and use fribidi dependency explicitly.
This is the same strategy used by Gtk.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/583
The `last_presentation_time` is usually a little in the past (although
sometimes in the future depending on the driver). When it's over 2ms
(`sync_delay`) in the past that would trigger the while loop to count up so
that the next `update_time` is in the future.
The problem with that is for common values of `last_presentation_time`
which are only a few milliseconds ago, incrementing `update_time` by
`refresh_interval` also means counting past the next physical frame that
we haven't rendered yet. And so mutter would skip that frame.
**Example**
Given:
```
last_presentation_time = now - 3ms
sync_delay = 2ms
refresh_interval = 16ms
next_presentation_time = last_presentation_time + refresh_interval
= now + 13ms
-3ms now +13ms +29ms +45ms
----|--+------------|---------------|---------------|----
: :
last_presentation_time next_presentation_time
```
Old algorithm:
```
update_time = last_presentation_time + sync_delay
= now - 1ms
while (update_time < now)
(now - 1ms < now)
update_time = now - 1ms + 16ms
update_time = now + 15ms
next_presentation_time = now + 13ms
available_render_time = next_presentation_time - max(now, update_time)
= (now + 13ms) - (now + 15ms)
= -2ms so the next frame will be skipped.
-3ms now +13ms +29ms +45ms
----|--+------------|-+-------------|---------------|----
: : :
: : update_time (too late)
: :
last_presentation_time next_presentation_time (a missed frame)
```
New algorithm:
```
min_render_time_allowed = refresh_interval / 2
= 8ms
max_render_time_allowed = refresh_interval - sync_delay
= 14ms
target_presentation_time = last_presentation_time + refresh_interval
= now - 3ms + 16ms
= now + 13ms
while (target_presentation_time - min_render_time_allowed < now)
(now + 13ms - 8ms < now)
(5ms < 0ms)
# loop is never entered
update_time = target_presentation_time - max_render_time_allowed
= now + 13ms - 14ms
= now - 1ms
next_presentation_time = now + 13ms
available_render_time = next_presentation_time - max(now, update_time)
= (now + 13ms) - now
= 13ms which is plenty of render time.
-3ms now +13ms +29ms +45ms
----|-++------------|---------------|---------------|----
: : :
: update_time :
: :
last_presentation_time next_presentation_time
```
The reason nobody noticed these missed frames very often was because
mutter has some accidental workarounds built-in:
* Prior to 3.32, the offending code was only reachable in Xorg sessions.
It was never reached in Wayland sessions because it hadn't been
implemented yet (till e9e4b2b72).
* Even though Wayland support is now implemented the native backend
provides a `last_presentation_time` much faster than Xorg sessions
(being in the same process) and so is less likely to spuriously enter
the while loop to miss a frame.
* For Xorg sessions we are accidentally triple buffering (#334). This
is a good way to avoid the missed frames, but is also an accident.
* `sync_delay` is presently just high enough (2ms by coincidence is very
close to common values of `now - last_presentation_time`) to push the
`update_time` into the future in some cases, which avoids entering the
while loop. This is why the same missed frames problem was also noticed
when experimenting with `sync_delay = 0`.
v2: adjust variable names and code style.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=789186
and most of https://gitlab.gnome.org/GNOME/mutter/issues/571https://gitlab.gnome.org/GNOME/mutter/merge_requests/520
We only call _clutter_input_device_update with devices that are not
Keyboard devices. Also passing a Keyboard device to a function whose
primary purpose is picking should be considered a bug in the caller.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/547
We're bailing out of clutter_stage_cogl_add_redraw_clip() early without
doing anything if we're ignoring redraw clips, so no need to call it if
we already know that will be the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/547
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Moving an actor with a ClutterDeformEffect applied flickers because
the depth_testing, setting the depth testing test function to
COGL_DEPTH_TEST_FUNCTION_LEQUAL fixes the problem.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/507
When the pointer is grabbed, we send the crossing events that are
initiated by this pointer only to the actor that has the grab. For
grabbed touch sequences, we always capture and bubble the crossing
events right now.
Fix this and make grabbed pointers and touch sequences behave the same
by sending touch crossing events only to the grab actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/422
It's important to cancel click actions when we get a touch cancel event,
otherwise the long press event might get emitted after the compositor
took over the touches because it detected a gesture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/396
Clutter does the nicety of connecting just created PangoContexts to
ClutterBackend signals in order to update it on resolution/font changes.
However the way the signals are disconnected (automatically via
g_signal_connect_object() auto-disconnect feature) may incur into
performance issues with a high enough number of ClutterActors with a
PangoContext (eg. ClutterText) as the lookup by closure is linear across
all signals and handlers.
Keep the handler IDs around, and disconnect them specifically on dispose
so it is more O(1)-ish.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556
The clutter/evdev implementation of mousekeys is designed after the
current implementation in X11, and works when the setting is enabled
regardless of the status of NumLock.
The GNOME documentation on accessibility features states however that
mousekeys work only when NumLock is OFF:
https://help.gnome.org/users/gnome-help/stable/mouse-mousekeys.html
Change the clutter/evdev implementation to match the documentation, i.e.
disable mousekeys when NumLock in ON so that switching NumLock ON
restores the numeric keypad behaviour.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/530
The keyboard accessibility setting "enable" is actually even more
misleading that initially anticipated, as it does not control the
entire keyboard accessibility feature, but just the "enable by
keyboard" feature, i.e. being able to enable or disable stickykeys
or slowkeys using various keyboard actions.
Yet the accessibility features should still work even if the "enable"
setting is unset, those can be controlled by the accessibility menu in
GNOME Shell for example.
Change the clutter/evdev implementation to match that behavior as found
in the x11 backend, so both backends are now consistent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/531
In a multi-monitor setup there is a separate paint run for each monitor.
If an actor doesn't intersect the first monitor painted then it is culled
out for that monitor to save time. Unfortunately this would mean
`clutter_actor_paint` was setting `is_dirty = FALSE` before the actor had
yet been painted on any monitor.
This meant that effects like `ClutterOffscreenEffect` were not receiving
the flag `CLUTTER_EFFECT_PAINT_ACTOR_DIRTY` when they should have, and
so would rightfully think they don't need to do a full internal
invalidation. So `ClutterOffscreenEffect`, and probably other effects,
did not repaint correctly unless on the first monitor in the list.
The fix is to simply avoid setting `is_dirty = FALSE` on those paint
runs where the actor has been culled out (`clutter_actor_continue_paint`
wasn't called). It is only safe to clear the flag after
`clutter_actor_continue_paint` has been called at least once per stage
paint.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1049https://gitlab.gnome.org/GNOME/mutter/merge_requests/511
clutter_input_device_get_physical_size was just used for device mapping
heuristics in MetaInputMapper. It now started using the info from udev
on for both backends, so this means this clutter API is no longer
necessary.
https://gitlab.gnome.org/GNOME/mutter/issues/514
Enabling keyboard accessibility features on Wayland from the keyboard
was wrongly assumed to be controlled by the "togglekeys" setting,
whereas it should be simply controlled by the "enable" setting.
As "togglekeys" is off by default and doesn't have a UI option to
enable, that would prevent turning on or off the keyboard accessibility
features using the keyboard.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/501
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
The ClutterVirtualInputDevice API was fixed to use Clutter button
internal codes, whereas the mousekeys still uses evdev codes.
Change the mousekeys implementation to use the Clutter button code
instead to remain compatible with the ClutterVirtualInputDevice API.
Fixes: 24aef44b (Translate from button internal codes to evdev)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/473
Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443
The clamped rectangle currently could not fully contain the original fractional
rectangle because it doesn't take care of the fact that the new width should
consider the fact that flooring we'd translate the rectangle, and thus to cover
the same area we need to take care of it.
So, to properly compute the width and height, calculate x2 and y2 first and then
use this ceiled value to compute the actual width using the floored x1 and y1.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
When we try to update the FB, we might face the case in which the effect target
framebuffer does not need any redraw, because it's already properly sized and
scaled, but the filter applied to the pipeline is not, because it has been
computed for a non-fractional scaling.
This is happens for example to clutter actors with a flattening effect (i.e.
override redirect mode set), that might have been generated properly for a
celied scaling level, but when we go fractional we need to ensure to use a
linear filter, as the 1:1 texel:pixel assumption is not true anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
At this level we use ceiled resource-scale when painting fractional value
When using fractional scaling we still need to create an integer-sized
texture and then we should paint it using a size which is proportional
to the real actor size ratio, and only paint a subsample of it, but this
doesn't seem to work properly with some weird scaling values.
Then, it's just better to draw the texture ceiled and then we scale it
down to match the proper actor scaling at paint level.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
When resource scale is set we need to generate a scaled PangoLayout (by adding
a new scale attribute, or adjusting the one we already have according the
resource scale), then it has to be painted with proper scaling matrix.
So everything that has to do with PangoLayout has to be in real coordinates,
then clutter logical coords multiplied by resource scaling.
While the actual size of the layout is the one of the PangoLayout divided by
resource scale.
We map the text positions to logical coords by default, while using
the pixel coordinates when painting.
We fall back to scale 1 when calculating preferred size if no scale is
known. The pango layout will not have set a layout scale attribute,
meaning it'll be 1, thus we should just assume the layout scale is 1 here.
Not doing so might result in the preferred size being 0x0 meaning the
actor won't be laid out properly.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/135https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
A clutter actor might be painted on a stage view with a view scale
other than 1. In this case, to show the content in full resolution, the
actor must use a higher resolution resource (e.g. texture), which will
be down scaled to the stage coordinate space, then scaled up again to
the stage view framebuffer scale.
Use a 'resource-scale' property to save information and notify when it
changes.
The resource scale is the ceiled value of the highest stage view scale a
actor is visible on. The value is ceiled because using a higher
resolution resource consistently results in better output quality. One
reason for this is that rendering is often not perfectly pixel aligned,
meaning even if we load a resource with a suitable size, due to us still
scaling ever so slightly, the quality is affected. Using a higher
resolution resource avoids this problem.
For situations inside clutter where the actual maximum view scale is
needed, a function _clutter_actor_get_real_resource_scale() is provided,
which returns the non-ceiled value.
Make sure we ignore resource scale computation requests during size
requests or allocation while ensure we've proper resource-scale on
pre-paint.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
This is an ABI break, hopefully an unimportant one since this signal/vmethod
is barely overridden.
The signal has been added an extra ClutterPaintVolume argument, and has been
given a boolean return value. The recursion to the parents has been taken
out of the default implementation and into the caller, using the returned
boolean parameter to control further propagation.
Passing the ClutterPaintVolume is easier on performance, as we don't need
setting this pointer as gobject data just to retrieve/unset it further
in propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
This basically reverts commit 54735dec, which tried to avoid the
GLib-defined types in favor the standard C ones. One exception to this
is the bool type, for which the commit introduces a new type CoglBool.
Let's just get rid of this type in favor of having consistency with the
GLib types. Note by the way that neither CoglBool nor gboolean (which
has a size of `int`) are completely compatible with bool (size `char`).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
Unfortunately, many parts of GNOME Shell and Mutter and Clutter
still use the implicit Cogl1 API. As such, it as a transition
between the old and new APIs, it is important to keep the
implicit draw framebuffer updated.
ClutterRootNode does not keep it updated though, and it might
lead to problems when rendering offscreen textures.
Fix that by pushing and popping the root node framebuffer on
pre- and post-draw, respectively.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
The ClutterRootNode paint node is theoretically the
top-most node of a paint nodes tree, except that we
are not in the point of having full rendering trees
in Clutter (all rendering performed by paint nodes
is still local and immediate).
When controlling the rendering tree, MetaShapedTexture
may need to paint into an offscreen framebuffer under
some circumstations.
Expose ClutterRootNode so that MetaShapedTexture can
use it to render to offscreen framebuffers.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
When painting to an offscreen framebuffer, MetaShapedTexture will
need to have full control of the painting routines of paint nodes.
As such, expose clutter_paint_node_paint() to allow forcing a
paint nodes paint from MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
The multitexture API is not a shortcut for multiple calls
to the single texture API. It is meant to wrap calls to
cogl_framebuffer_draw_multitexture_rectangle(), which
uses the passed texture coordinates at different layers of
the pipeline.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterImage is a ClutterContent implementation that
has an internally managed CoglTexture. This texture
is recreated when new image data is set.
ClutterContent implementations may have control over
the allocation of the widgets they're attached to,
through CLUTTER_REQUEST_CONTENT_SIZE. On those cases,
if the new image data differs in size from the previous
data, it is important to notify those actors about the
size change. However, currently ClutterImage does not
notify them.
With the introduction of clutter_content_invalidate_size(),
it is possible to report the size changes to attached
actors.
Adapt ClutterImage to invalidate_size() when image data
has different sizes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterContent has the ability to dictate the layout of any
given actor, through the CLUTTER_REQUEST_CONTENT_SIZE request
mode.
However, there is no way for ClutterContent implementations
to notify their attached actors that the content size changed.
Add a new optional ClutterContent.invalidate_size() vfunc and
clutter_content_invalidate_size().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
When profiling gnome-shell it was found that one of the main triggers
of `clutter_actor_queue_relayout` during animations was
`clutter_actor_set_margin_internal` continuously setting the same
zero margins. That's obviously pointless and also expensive. So just
avoid redundant margin changes.
This helps to further improve performance in:
https://gitlab.gnome.org/GNOME/mutter/issues/233,
https://gitlab.gnome.org/GNOME/gnome-shell/issues/349
This change previously landed as 59acb3895 and then got reverted because
it was found to make gnome-shell#517 worse. However that bug now has a
proper fix and this branch isn't really directly related so is being
reproposed...
Just move the minimal bits to this ClutterKeymapEvdev object. Much
of the functionality of a keymap is spread along ClutterSeatEvdev,
ClutterDeviceManagerEvdev and ClutterVirtualInputDevice. Future
refactors are due here.
Also, ideally keymaps are per-seat objects (at least keyboard state
is). We don't expose much info about seats altogether outside the
evdev device manager implementation. We just poke the main seat at
places, but eventually seats should be public.
We thus far have similar objects/code internal to backends. Expose the
minimum API necessary to cater for gnome-shell as a generic object.
So far only the X11 backend has an actual GObject for it, and was made
to be a subclass right away.
`distribute_natural_allocation` expects an input >= 0 of type `gint`. In
`get_preferred_size_for_opposite_orientation` it is used with an unchecked
variable `size` of type `gfloat`, which in case it is `Infinity`, gets
passed on in the macro `MAX (0, size)`. `Infinity` becomes `G_MININT`
when implicitly casted to `gint` in `distribute_natural_allocation`,
triggering the assertion `extra_space >= 0`.
The resulting warning in the log is counter intuitive and not very
helpful.
Use `float` in `distribute_natural_allocation` instead of `gint` and
assert on denormal values so we can more easily identify bugs.
Additionally change some types while at it and add a even more
expressive warning referencing the actor at one point.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/375
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
`ClutterOffscreenEffect` had been getting the wrong bounding box in the
case of clones and descendents of clones, causing visibly incorrect
clipping. This was due to `clutter_actor_get_paint_box` only ever being
given the source actor during a paint (which is correct) and not the clone.
Even if we weren't painting a clone but an offscreened descendent of a
clone (like in gnome-shell's desktop zoom), we would get the wrong result.
Fortunately we don't need to know the actual clone/actor being painted so
don't need to call the problematic `clutter_actor_get_paint_box` at all.
The solution is to only keep untransformed rendering in the FBO and leave
the correct transformation for later. The correct clone/actor's
transformation is already set for us as the current cogl modelview matrix
by `clutter_actor_paint`.
Bonus optimization: This all means we don't need to keep `last_matrix_drawn`
or force a full repaint every time some part of the transformation changes.
Because the FBO contents are no longer affected by transformations. As it
should be. In other words, offscreen-effected actors can now move around
on screen without themselves being repainted.
Special thanks to Mai Lavelle for identifying the cause of the problem.
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=789050,
https://bugzilla.gnome.org/show_bug.cgi?id=659523#c9,
https://gitlab.gnome.org/GNOME/mutter/issues/196,
https://gitlab.gnome.org/GNOME/mutter/issues/282,
https://gitlab.gnome.org/GNOME/gnome-shell/issues/387,
https://launchpad.net/bugs/1767648,
https://launchpad.net/bugs/1779615
pkg-config files for mutter are generated using *_pkg_deps as requires, but
programs linked with libmutter doesn't need most of these private dependencies
which are only needed for building and linking mutter and its subprojects.
So list packages needed only by mutter itself inside *_pkg_private_deps and
don't expose such packages to pkg-config, but only use them at build time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Clutter exports symbols explicitly using `CLUTTER_EXPORT`, so everything should
be hidden by default, unless exposed.
Usage of `gnu_symbol_visibility` needs a version bump to meson 0.48.0
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Soname of the libraries should be the major version number, while the version
triplet is currently used:
objdump -p libmutter-4.so.0.0.0 | grep SONAME
SONAME libmutter-4.so.0.0.0
While is expected to be only libmutter-4.so.0
Fix all shared libraries by setting valid version and soversion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
The const qualifiers were implicitly discarded here and there. Avoid that
either by adding the constness, or casting it away when a const variable
is passed to a function that is defined as non-const but effectively
expect a const.
This will be used by the screen casting code to check whether it should
wait for a frame before reading cursor state, or send only the cursor
update, if no redraw is queued.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
Keycode lookup can fail for serveral reasons, e.g. if there is no combination of
modifiers and keycodes that can produce the target keysym with the current
keyboard layout.
In case the keycode lookup fails, remap temporarily the keysym to an unused
keycodes.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/109
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
If a library is provided in the positional arguments, then meson
defaults to installing the .pc file in a 'pkgconfig' subdirectory
in the library's install location. We want the files in the regular
$libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so
specify the location explicitly in the parameters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
Dependencies are added automatically, and we no longer get warnings
like:
clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4
was passed to the "libraries" keyword argument of a previous call to
generate() method instead of first positional argument. Adding
mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour
that will change in a future version of Meson. Please report the issue
if this warning cannot be avoided in your case.
This makes the build less verbose, as all .gir generation except for
clutters didn't pass --quiet to g-ir-scanner, making it output long
linking commands. Do this by adding a common introspection_args
variable.
While at it, put -U_GNU_SOURCE in there too, as it was always passed
everywhere as without it the scanner would log warnings.
The actor-shader-effect test actors are 50px wide, but we check the 51st
pixel. This went along undetected until "clutter: Avoid rounding
compensation when invalidating 2D actors" because the paint volumes were
made slightly bigger and the shaders paint all over them (I guess nobody
noticed those actors being actually ~52px wide).
Update the test to check the middle of the opposite edge, so we keep neatly
rounded numbers.
The test does a clutter_actor_set_scale_full() call that only updates
the scale center (i.e. no changes to scale-x/y), but expects to receive
notifications of actor scale changes.
Since "Revert "Revert "ClutterActor: Optimize away idempotent
scale/position updates"" these are optimized away, so just drop the
assumption.
This allows the redraw clip to be more constrained, so MetaCullable doesn't
end up rendering portions of window shadows, frame and background when a
window invalidates (part of) its contents.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Since now we don't set the swap throttled value based
on sync-to-vblank, we can effectively remove it from
Cogl. Throttling swap buffers in Cogl is as much a
historical artifact as sync-to-vblank. Furthermore,
it doesn't make sense to disable it on a compositor,
which is the case with the embedded Cogl.
In addition to that, the winsys vfunc for updating
whenever swap throttling changes could also be removed,
since swap throttling is always enabled now.
Removing it means less code, less branches when running,
and one less config option to deal with.
This also removes the micro-perf test, since it doesn't
make sense for the case where Cogl is embedded into the
compositor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
Externally setting the sync-to-vblank setting was a feature
added as a workaround to old Intel and ATI graphic cards, and
is not needed anymore. Furthermore, it doesn't make sense to
change it on a compositor whatsoever.
This commit removes all the ways to externally change this
setting, as well as the now unused API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
The xf86-input-wacom driver exports a property with the tool type as known by
the driver. This is a more reliable choice than guessing based on the device
name.
In the touchscreen case, we simply use is_touch_device() to guess which one of
the two options it is. Note that this code should never be hit anyway as we
would've succeeded earlier with a previous is_touch_device() call.
If we are lucky enough and the parent actor has the CLUTTER_ACTOR_NO_LAYOUT
flag, we would skip the relayout, but still redraw the parent actor in its
entirety.
In these cases, we can at least just redraw the area affected by the actor
being shown/hidden.
These calls don't actually affect the layout, but the paint order.
It seems safe to skip the full relayout/repaint of the parent actor,
and redraw only the area occupied by the affected child.
cogl_(fromebuffer)_set_viewport will implicitly cast away the fraction
of a floating point number, meaning if a coordinate calculation
resulted in just below the integer (which for example ~1.75 scaling on
a 1920x1080 did), we'd set a one pixel too narrow viewport. Fix this by
always rounding the floating point to the closest int before passing,
avoiding the precision loss.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This is to ensure we're rendering a red damage area that actually
represents what is being damaged.
Fixes an always-fullscreen red damage on bare metal Wayland and
GNOME Shell.
This is useful to visualize which parts of the screen are being
damaged.
Add a new 'damage-region' value for CLUTTER_PAINT and paint the
damaged regions accordingly.
This commit includes following fixes for a few shell scripts:
1. Follow the best practice of quoting variables everywhere unless they
are used in places where word-splitting and globbing can never happen.
2. Replace `command` with $(command) because the latter is easier to use
and read.
3. Don't use "$@" in places expecting a string because it is an array
of strings instead of a single string.
Bash is not always installed in /bin and we should not hardcode the path
of it in source code which is expected to be built on many operating
systems and distributions.
Since most scripts using #!/bin/bash here doesn't have any bashism,
they can be converted to #!/bin/sh instead of using /usr/bin/env trick.
If a device (virtual or real) is removed while there are remaining
events queued for that device, the event loop may try to access the
event freed memory.
To avoid the issue, add a reference to the device when the event is
created or copied, and remove the reference once the device is freed.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/393
Mostly as expected, this port is also trivial. A small cleanup
accompanies this patch, making gen_texcoords_and_draw_cogl_rectangle()
receive the framebuffer that it should draw into.
Because ClutterText has a somewhat convoluted drawing routine,
replacing cogl_rectangle() here isn't as straightfoward as the
effects were.
A new CoglPipeline is now part of the ClutterText struct, and
is used to set the color of the background or the selection.
Another change is paint_selection() now receives a framebuffer
to draw into. The check for NULL framebuffer does not make
sense here, since there is always a draw framebuffer set
when in the drawing function. Because of that, the check is
now gone.
All those effects have the same basic pattern of setting a
color of a pipeline, then drawing a rect with cogl_rectangle().
Thus, replacing those was as easy as retrieving the draw
framebuffer and calling cogl_framebuffer_draw_rectangle() on it.
The default implementation of ClutterActor.pick() uses
cogl_rectangle() to draw the rectangle with the color
for picking.
Replace that by cogl_framebuffer_draw_rectangle(). A
static color pipeline had to be created in order to
hold the pick color.
Instead of using cogl_read_pixels(), which is deprecated and
uses the implicit framebuffer, pass the current CoglFramebuffer
and use cogl_framebuffer_read_pixels().
Another case of a simple and direct API translation. Instead of
using the deprecated cogl_clear() function, replace it by the
non-deprecated cogl_framebuffer_clear().
The events-touch test tested that clutter could properly process evdev
touch events. It used uinput to post evdev touch events, thus only ran
when runnig the test as root. Running as non-root it'd just silently
pass. As Clutter doesn't process evdev touch events anymore,
libinput does, so the test is fairly pointless, so remove it.
Pausing the master clock didn't actually pause it if there was already a
scheduled frame in progress. This is problematic if one actually expects
to see no new frame scheduling to happen after pausing, for example it
caused actor 'pre-paint' to be signalled on actors, but nothing was ever
painted.
Avoid this by destroying the master clock source when pausing, and then
recreating it when resuming.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/309
When profiling gnome-shell it was found that one of the main triggers
of `clutter_actor_queue_relayout` during animations was
`clutter_actor_set_margin_internal` continuously setting the same
zero margins. That's obviously pointless but also expensive since it
incurs full stage relayouts and reallocation. So just avoid redundant
margin changes.
Helps to further improve:
https://gitlab.gnome.org/GNOME/mutter/issues/233,
https://gitlab.gnome.org/GNOME/gnome-shell/issues/349
Almost a decade old, lets just assume it's there. This makes the button
on cally-atktext-example work again when building with meson, and
probably other things too.
If texture allocation fails (e.g. on an old GPU with size limit 2048)
then `update_fbo` would return `FALSE` but leaves `priv->offscreen`
as non-NULL. So the next paint will try to use the offscreen with a
`NULL` texture and crashes. The solution is simply to ensure that
`priv->offscreen` is NULL if there is no `priv->texture`, so the default
(non-offscreen) paint path gets used instead.
Bug reported and fix provided by Gert van de Kraats.
https://launchpad.net/bugs/1795774
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
This allows input methods to inject key events with specific keyval/keycode,
those events will be flagged with CLUTTER_EVENT_FLAG_INPUT_METHOD so they
won't be processed by the IM again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/531
If the user maps eg. Alt+F2 to a pad button, the MetaInputSettings will
send the full Alt press, F2 press, F2 release, Alt release sequence.
However the keycode corresponding to Alt is found in level 1, so the
Shift modifier gets unintendedly latched in addition to the Alt key
press/release pair.
We could probably improve keycode lookup heuristics so level=0 (and
no modifier latching) is preferred, but we can do without it altogether
for modifier keys.
If an effect is active and it overrides the paint volume, we should
always recompute the paint volume when requested and not use the
cache, since the paint volume override can change from call to
call depending on what phase of painting we are in. For instance,
if we are part way through painting effects and request the
paint volume, the paint volume should only go up to the current
effect, but in a later call to compute repaint regions, the
paint volume needs to expand to accomadate the effect.
This still involves a lot of recomputation in the case of effects -
in a later clutter version it would be worth adding an API to
allow effects to explicitly recompute and return a new the paint
volume up to the current effect as opposed to recomputing
the cached one.
Previously we were checking l->data != NULL || (l->data != NULL &&
l->data != priv->current_effect). This would continue the loop even
if l->data == priv->current_effect, since l->data != NULL, which was
not the intention of that loop.
We also don't need to check that l->data != NULL before checking if
it does not match the current_effect, since we already checked
that current_effect was non-NULL before entering the loop.
Some tablets have a noticable pointer jump on tip down/up, causing unintended
lines during drawing. Likewise, a button event may have an axis update that we
currently ignore. libinput provides tablet axis events only if no other state
changes, the client must instead get the current axis data from the tip/button
event. So let's do this, process the event axis data during tip/button as
well.
A libinput recording to reproduce is the 'dots.yml' in
https://gitlab.freedesktop.org/libinput/libinput/issues/128Fixes#289
Unfortunately XKeysymToKeycode() falls short in that it coalesces keysyms
into keycodes pertaining to the first level (i.e. lowercase). Add a
ClutterKeymapX11 method (much alike its GdkKeymap counterpart) to look up
all matches for the given keysym.
Two other helper methods have been added so the virtual device can fetch
the current keyboard group, and latch modifiers for key emission. Combining
all this, the virtual device is now able to handle keycodes in further
levels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/135
A just focused ClutterInputFocus must set itself up correctly on
all situations. Refactor this into a function, so it can be used
for the case where a ClutterText gets editable while focused.
`ClutterText` painting for editable single_line_mode actors like `StEntry`
is always clipped by:
`cogl_framebuffer_push_rectangle_clip (fb, 0, 0, alloc_width, alloc_height)`
So it's difficult to get the rectangle wrong. However in cases where the
target framebuffer has changed (`cogl_push_framebuffer`) such as when
updating `ClutterOffscreenEffect` we had the wrong old value of `fb`. And
so would be clipping the wrong framebuffer, effectively not clipping at all.
Sending button events to a ClutterVirtualInputDevice, the API expects
button codes to be of the internal clutter type. The evdev
implementation incorrectly assumed it was already prepared evdev event
codes, which was not the case. Fix the evdev implementation to translate
from the internal representation to evdev before passing it along to
ClutterSeatEvdev.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/190
Children added to a parent after that parent (or its ancestors)
have already been cloned now inherit the clone branch depth of
the parent. Otherwise `clutter_actor_is_in_clone_paint` on the child
could return FALSE when it should have been returning TRUE.
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
`modelview` is uninitialized and the `apply` function just multiplies it.
What we really want is to initialize `modelview` so replace `apply` with
`get`.
Who knows what bugs this may have caused...
Treat the main seat as other seats, so we don't have to handle it differently
in specific places. This was already the case before when a real device
was plugged before the startup, but not applied when hotplugging a device.
When no input devices are available on startup the device manager might be fast
enough to be constructed so that no default stage is set yet, and thus when
main seat virtual devices are created they won't have a proper stage set.
If then we plug a real device, the events that an input manager could generate
won't be associated to any stage and thus won't be processed.
We need then ensure that when we update the stage for the device manager we
(un)associate it also to the main seat devices.
In devices such as ARM boards there could be no input devices connected on
startup, leading to a crash when we try to process artificial events that
could be queued (as gnome-shell does when syncing pointer).
Those events still should refer to a device and, in case we don't have one
provided by libinput we should still return the core devices defined in the
main seat.
The fix is twofold. On one hand, it makes sense not to relate IM (nor
any other) generated events to a HW device. On the other hand, if we
are unfortunate that an IM event is in flight when we are switching
to another TTY, it may arrive at a time when the source device is no
longer existent.
Mark CAPS lock as a modifier (as it should) so that when using XKB
options to change the default behaviour of CAPS lock, the new assigned
key can by used as a sticky key as well.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/112
Input method can inject key events, which leads to multiple reported key
press/release events for a single user action.
Ignore those events as this confuses keyboard accessibility.
And make the ClutterText-level properties independent from the input
focus, as those properties can be set anytime, not just when the
ClutterText actor is focused.
https://gitlab.gnome.org/GNOME/mutter/issues/66Closes: #66
We can save an unnecessary relayout if the required size to fully draw the text
is equal to the currently allocated size after the underlying text buffer or
attributes that only affect the PangoLayout have changed.
Actor keybindings were dispatched in an earlier return path, which means
the IM doesn't get to see certain key events. Flip the order around so the
IM has an opportunity to handle all keypresses.
https://gitlab.gnome.org/GNOME/mutter/issues/65Closes: #65
IF two touch devices have colliding touch point IDs they'd interfere on
the seat. To avoid this, always allocate a seat wide slot for each
device wide slot, but don't use device slots directly in the seat.
Checking correct state is responsibility of the ClutterInputFocus user, and
it is indeed possible to get a focused ClutterText while its
ClutterInputFocus didn't get itself focused (eg. lack of IM).
https://gitlab.gnome.org/GNOME/mutter/issues/36Closes: #36
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
clutter_set_viewport always operates on the draw fb, but
mutter sometimes has an offscreen fb it uses instead.
This commit uses the non-deprecated, clutter_framebuffer_set_viewport
function, which takes an explicit fb argument.
Closes: https://gitlab.gnome.org/GNOME/mutter/merge_requests/2
This function returns TRUE if there is any preedit going on. This method
will be useful in gnome-shell where similar checks are performed on
StIMText actors.
ClutterInputFocus is an abstract object to be subclassed by UI actors and
the wayland interface and represents the user of an input method. It
represents the current focus of the input method, so all emitted signals
and public API hooks are expected to be called when the input method is
currently interfacing with the input focus.
ClutterInputMethod is an abstract class (to be implemented in the upper
layers) that represents the input method itself. Besides focus management
itself, all public API calls that would be called by the subclasses are
delivered through the current input focus.
Libinput shall report those as having slot=-1, which gets mistakenly
translated into the special "NULL" ClutterEventSequence. Making those
events get a non-NULL sequence will make single touch devices work.
https://bugzilla.gnome.org/show_bug.cgi?id=792005
We might receive touch events for unknown touch points, for example
when starting mutter while touching the screen (resulting in no
touch-down event ever being received). Avoid crashing when this happens
by just dropping these events on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=791371
When capture_view* functions are called with the paint flag set
to TRUE, we need to setup the framebuffer, however this was
happening after setting up the viewport, while the viewport
needs the framebuffer to be valid when calling cogl_set_viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=791809
On VT switch, the xkb state layout index is lost and reset to the first
group, so if the first layout is not the last one being used, the xkb
state used in both meta-wayland-keyboard.c and clutter/evdev will be
desynchronized with the keyboard source indicator in the gnome-shell UI.
Save the effective layout chosen along with the seat so it can be
restored when reclaiming devices.
Use the saved layout index from the clutter/evdev's seat to restore the
layout in meta-wayland-keyboard, so that switching VT doesn't reset the
layout and causes further discrepancies with the layout indicator in the
gnome-shell UI.
https://bugzilla.gnome.org/show_bug.cgi?id=791383
Adds a set of convenient functions that can be shared between x11 input
device backends (namely core-x11 and xi2) to control XKB accessibility
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Implementing keyboard accessibility in clutter means we need to be able
to notify higher layers of possible modifier masks or setting changes
(as some keyboard accessibility can be disabled or enabled by keyboard).
For this purpose, add two new signals:
ClutterDeviceManager::kbd-a11y-mods-state-changed
ClutterDeviceManager::kbd-a11y-flags-changed
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Use a set of bitwise enum flags to set different keyboard accessibility
features and the necessary vfunc hooks in clutter input device so that
keyboard preferences can be passed to different input device
implementations.
The idea is to be able to configure either the clutter own
implementation of keyboard accessibility for evdev, or eventually
configure AccessX from the X11 clutter input device using the same
mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
On X11, when AccessX is enabled, all X11 clients benefit from the
AccessX features, including gnome-shell/mutter, meaning that special
keys like the overview or other shortcuts are also affected.
To achieve the same in Wayland, we need to implement the same features
in clutter main rather than the Wayland backend, so that all depending
code within the compositor but also Wayland clients (which rely on the
compositor to get keyboard events) similarly benefit from the
accessibility features.
Add hooks to the clutter main loop to be able to implement such
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
We'll need a way to trigger a bell from within clutter for keyboard
accessibility features, add the necessary hooks to be able to call a
backend bell-notify method.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
The capture_into() function wrote out of bounds when capturing from a
non-origin view (not positioned at (0,0)). At the time of
implementation, this API was used to capture pixels across views into a
single data buffer, but the way it's used, and the way views may work
now, makes this impossible to do properly.
So remove the ability to capture into a pre-allocated buffer from
multiple views, and complain if the passed rectantgle overlapps with
multiple views. This removes the broken offset calculation all
together, fixing the bug motivating this change.
https://bugzilla.gnome.org/show_bug.cgi?id=787715
The reverted commit seems to cause
https://bugzilla.gnome.org/show_bug.cgi?id=787240 for some reason. Lets
be safe and revert it for now, as the code freeze is just around the
corner.
This partly (it doesn't reintroduce a whitespace issue) reverts commit
dbc63430d8.
Add API similar to clutter_stage_capture() but that draws into
externally allocated memory. It is assumed that the pixel format is
ARGB32, and the memory is structured in a way that the width of the
passed rectangle is identical to the stride divided by 4.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
If CLUTTER_CURRENT_TIME is passed, let the backend find an appropriate
time stamp representing the current time in the clock that is used by
that backend.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
When suspending (i.e. VT switching away, the GDM gnome-shell instance
gets hidden, or changing user), destroy the onscreen and offscreen
monitor framebuffers. When resuming, the stage views and framebuffers
will be recreated anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=786299
Message was poking stage_x11, which doesn't exist in this context.
Just print the Window that is receiving the event, the event will be
emitted into the only existing stage anyway.
Adds basic support for the "wheel" event from the Wayland tablet protocol.
Ideally we would accumulate the angle and report a wheel event with an
appropriate value for "clicks". We can get away with a much cruder method
for the time being, however, since no Wacom tablet puck actually provides
a smooth scrollwheel. Checking whether the angle in CLUTTER_INPUT_AXIS_WHEEL
exceeds a nominally-small threshold is sufficient to determine that the
wheel has advanced by at least one physical click.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
These events will be useful on gnome-shell UI, so translate the
4-5 button events with exotic axes to those. Also use the
XI_Motion event received when first touching those to reset
the ring/strip state, so we don't receive spurious direction
changes in the upper layers.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
When fractional scaling is used, damage and paint clip region is tracked
in stage coordinate space using integers might end up missing some
pixels when the border ends up on half pixels. Change the damage
tracking and clip regions to be in buffer coordinates so we can align
damage on physical pixel borders.
However, just using rounding up to the next physical pixel results in
glitches. To avoid this, extend the damage by one logical pixel in all
directions, but still (scissor) clip the drawing to the non-extended
region, as otherwise drawing the damaged regions will result in
incorrect pixels on the right and bottom edges of the clip region. It is
possible that there are better ways to do this, which can be explored in
the future.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
We always hit non-fractional floats here because the stage views are
always made so that they are aligned on integer positions with integer
sizes, but there is no reason to go float -> int -> float when
calculating the viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Make clutter_stage_capture() work if views are scaled. This needs
adaptations on the using side to deal with the cairo surface device
scale that is used to communicate the scale used when capturing.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To support fractional scaling, change the stage view scale to be a
float instead of an int. Also change the places where it is retrieved
and used when scaling things.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Previously gnome-shell listened on the Xft Xsettings via GTK+s
GtkSettings to get the font DPI setting. The Xsetting might not
be what we want, and we should not rely on Xsettings when we don't need
to, so lets manage it ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
These should be set one, but just set the master to be the slave
pad device. We are passively grabbing the pad device, so this is
consistent with active grabs on slave devices. Besides, pads are
paired to the VCP, which is not really truthful.
Fixes inoffensive warnings when trying to check whether motion
throttling applies for these events.
https://bugzilla.gnome.org/show_bug.cgi?id=784881
When building against a glib-genmarshal from GLib 2.54 we can use the
`--prototypes` command line argument to generate the prototypes for the
marshallers in the C source, and avoid a missing-prototypes compiler
warning.
Since commit 5cb5baa7d4, we skip transitions when updating an
actor's scale/position to the existing value. As a result, we
don't get change notification on those properties either - given
that the properties did not actually change, that behavior seems
fine, so just modify the test to not expect a notify signal for
unchanged properties.
Commit 0fd9e38175 fixed setting the out parameter for the x coordinate
when using the X11 backend, but broke compilation when the backend is
not available ...
Really fix the issue by running the X11-specific code when the X11
backend is available and in use, and display the one-time warning
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=781902
GLib now generates the prototypes for the generated marshallers, so it's
not necessary to include the header any more.
This fixes a build failure in GNOME Continuous with GLib master, caused
by -Werror=redundant-decls.
Due to an accidental swap of an else statement and a preprocessor #else,
the output x coordinate is currently only set when not using the X11
windowing system, whoops.
https://bugzilla.gnome.org/show_bug.cgi?id=781902
Window scaling is a clutter feature used to enable automatic scaling of
stage windows when running under as an application in windowing system.
Clutter in mutter does not support running as a stand-alone application
toolkit, so lets remove this unused feature.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit adds the ability to set a scale on a scale view. This will
cause the content in the stage view to be painted with the given scale,
while still keeping the configured layout on the stage. In effect, for
a stage view with scale 'n', this means the framebuffer of a given stage
will 'n' times larger, keeping the same size on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Clutter's evdev input backend has no support for setting double
click timeout set by gnome-settings-daemon. This results in
touchpad click events timing out on wayland, because the
default timeout value wasn't enough.
This patch moves timeout setting to mutter and removes X11
backend specific setting from clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=771576
This will be used to invert the transform in the nested mode, making it
possible to test offscreen texture based transform using the nested
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
In order to minimize the amount of breakage, while at the same time
making it easier to make backward incompatible changes needed to
continue turning libmutter into a capable Wayland compositor, make the
libmutter and friends (libmutter-clutter, libmutter-cogl*) parallel
installable by adding a version number to the name. This changes
various filenames, for example what previously was libmutter.so is now
libmutter-0.so (assuming the version for now is 0), and
libmutter-clutter-1.0.so is now libmutter-clutter-0.so. The pkg-config
filenames and GObject introspection has been renamed to reflect this as
well.
This enables a downstream compositor rely on a specific version of the
libmutter API, while gracefully handling API/ABI changes by having to
update to the new version at their own pace.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
When != 0, this property will express the W:H ratio of the desired
output area (be it one monitor or the span of all monitors). At
the time of translating coordinates, coordinates will be skewed so
that the input area of the tablet is a rectangle of the given ratio.
Events happening in the input areas that fall outside the output
aspect ratio will be clamped to the nearest coordinate in the rect.
If the ratio is 0, the whole input area of the tablet will be used
and no coordinate skewing will happen.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
And transform absolute events using this matrix. This property is
akin to the "Coordinate Transformation Matrix" property in X11,
and will be used to map tablets/touchscreens to outputs, favoured
over the libinput matrix which is meant for calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
Clutter assumed seat0 which is most usually, but not always correct.
Add an evdev-backend specific function to allow passing the seat
that will be used for ClutterDeviceManager construction, which we
already obtain in MetaLauncher.
https://bugzilla.gnome.org/show_bug.cgi?id=778092
Since both the libinput event source and the key repeat timer have the
same priority, the order in which both handlers are called is
arbitrary if both sources are ready on the same poll return. This
means that sometimes we generate key repeats when there's already a
real key event queued on libinput that would cancel the repeat timer
if only it was processed before.
One solution would be lowering the repeat timer source priority a
notch lower than the libinput source but that would mean that a steady
stream of events from libinput (e.g. pointer device motion) would
prevent any key repeats to happen.
Instead, we can fix this problem by trying to dispatch libinput from
the key repeat timer and checking if the timer source has been
destroyed before generating more key repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Commit 9214d5029c changed the notify*
API to use microseconds and we already have a microsecond time source
here so we can use the timestamp directly without losing resolution at
this layer.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
This is implemented using Wacom-driver specific properties at
the moment, until libinput becomes the fallback driver handling
tablet and pad management.
Whenever a tool becomes in proximity, a new ClutterInputDeviceToolXI2
will be created (if it wasn't created previously) for the given
serial number. This tool will be set in all events send from the
device.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We do so whenever a tool enters or leaves proximity. We now also
ensure that last_tool is NULL after it leaves proximity, although
the CLUTTER_PROXIMITY_OUT event itself should still contain tool
information.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We most notably handle button events (acquired through a passive grab on
all device buttons) which are translated to CLUTTER_PAD_BUTTON* events,
so there is generic handling of pad actions on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Commit 5fbb479301 was wrong too. What we
really want to do here is getting view relative coordinates given the
view's and the rectangle's global coordinates so we need to subtract
the view's origin from the rectangle's.
https://bugzilla.gnome.org/show_bug.cgi?id=771502
Commit a4fb7ef5a3 dropped translations of our internal cogl/clutter
forks, which broke the local-based text direction support. Instead
of bringing back translations just for this purpose, we can re-use
GTK's translations which use the same technique.
https://bugzilla.gnome.org/show_bug.cgi?id=771549
Now with the existance of offscreen view framebuffers the buffer age
damage regions are only valid if the view in question doesn't doesn't
have an intermediate offscreen. So, for views that doesn't have buffer
age, return the dirty pixel (0,0).
https://bugzilla.gnome.org/show_bug.cgi?id=770672
When blitting an offscreen onto an onscreen, the whole offscreen should
always be drawn on the whole onscreen. Thus, don't try to convert
between coordinate spaces, just draw the whole offscreen on the whole
onscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=770672
Clutter discards any motion event if next event happens to also be a
motion event. This is problematic when the motion event carries
relative motion deltas, since the information about them is completely
lost.
Until we have moved away made the stage stop discarding motion events,
lets work around the issue by compressing them, effectively adding
multiple relative motion deltas together, would one be discarded.
https://bugzilla.gnome.org/show_bug.cgi?id=771049
The rectangle passed to capture_view() is in stage coordinate space;
thus, to translate to framebuffer coordinate space, the origin need to
be translated by the view layout position.
This fixes capturing views not at position (0, 0).
https://bugzilla.gnome.org/show_bug.cgi?id=770127
Absolute pointer events used the X coordinate as both X and Y. This
caused the pointer cursor to be moved incorrectly for absolute pointer
devices, commonly used in virtual machines.
https://bugzilla.gnome.org/show_bug.cgi?id=770557
"Blit" the result on the framebuffer after each view is painted.
This of course only applies if there is an offscreen buffer to
perform any blitting. Otherwise the onscreen framebuffer is rendered
to directly and this step is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The offscreen is given through the ::back-buffer property, the ClutterStageView
will set up the the CoglPipeline used to render it back to the "onscreen"
framebuffer.
The pipeline can be altered through the setup_pipeline() vfunc, so ClutterStageView
implementations can alter the default behavior of blitting from offscreen to
onscreen with no transformations.
All getters of "the framebuffer" that were expecting to get an onscreen have
been updated to call the right clutter_stage_view_get_onscreen() function.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Various clutter test directly use cogl symbols, so they should be linked
against mutter-cogl as well.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769636
This is somewhat gross at the moment, because we're after all mimicking
real keyboard events, we can only lookup keycodes that are available
in the current map, and the control of levels is rather limited.
Eventually, we want to implement the text_input protocol, handle these
events separately to MetaWaylandKeyboard, so event->key.keyval is
is guaranteed to be the final result. Until then, this is the farthest
we can get.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Evcodes don't cut it when we have something already specifying the
character to be printed, despite the current group/level. This API
allows some more control on the intended output.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
libinput does it for us, but only for physical devices. When we add
virtual devices to the same seat, we need to track button press count
ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Virtual input devices aim to enable injecting input events as if they
came from hardware events. This is useful for things such as remote
controlling, for example via a remote desktop session.
The API so far only consists of stumps.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Depending on clutter_input_device_get_mapping(), or whether the current
tool is either cursor or lens (those don't make any sense in absolute
mode), relative motions will be reported.
This function call only applies to tablets, and thus will error
out unless it's called with CLUTTER_TABLET_DEVICEs. This will
allow setting absolute/relative mapping on those on the fly, as
this is optional.
This will only be practical for pads (and maybe generic buttonsets in
the future?), we just need to know the number as the events will also
contain a number as the identificator.
Those map closely what we get from libinput. Button events have
been made its own separate struct, its semantics fall somewhere
in between of ClutterButtonEvent and ClutterKeyEvent, so is better
emitted as its own set.
Currently the setter doesn't take ownership of the value, but dispose()
will unref it (and thus release someone else's reference). Fix this by
taking ownership of the property value in the setter.
There's no need for a cast for printing an object's type or address,
so we can remove variables that are unused when not building with
CLUTTER_ENABLE_DEBUG.
Mutter (and libmutter users) are the only users of this version of
cogl, and will more or less only use the cogl-1.0, cogl-2.0 and cogl
experimental API variants, and having the possibility of having
different API versions of the same API depending on what file includes
it is error prone and confusing. Lets just remove the possibility of
having different versions of the same API.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We bypass our build configuration to fetch API from a version which
isn't the one we actually use. Stop bypassing and just admit that the
1.0 API is still there, but still deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We didn't include clutter-build-config.h, meaning we included a
different API of cogl than the rest of clutter. This API contains the
function cogl_sqrti which was the only thing used. Lets include the
build config file and stop depending on the API that is no longer
exposed to us.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of assuming there is a single onscreen framebuffer, use the
helper functions for setting the frame callback and getting the frame
counter.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The actor-offscreen-redirect didn't initialize its state properly, so
it could potentially end up with the "was_painted" state being TRUE
from the start, effectively skipping the whole test.
Fixing so that the test even run resulted in the test getting stuck in
a dead lock due to the verification that a frame was drawn was done
from a paint callback. A paint callback had the mutex held, so when the
test case tried to run the main loop, the next paint callback caller
path taken would try to re-lock the same mutex, thus dead lock.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In cogl use cogl-config.h and in clutter use clutter-build-config.h. We
can't use clutter-config.h in clutter because its already used and
installed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Since the check for backend->cogl_context was accidentally moved
to clutter_backend_do_real_create_context, the Glib source that
is created at the end of clutter_backend_do_create_context() is
created and added each time create_context() is called, though
create_context() is supposed to be idempotent.
https://bugzilla.gnome.org/show_bug.cgi?id=768243
The 'select-all' action is currently only bound to <ctrl>a, which makes
it awkward to use when caps-lock is active, and is inconsistent with GTK+.
Just accept both upper- and lower-case variants.
https://bugzilla.gnome.org/show_bug.cgi?id=766326
The device name is something more natural, similar to what's seen
in X11, the sysname is rather the event node basename, which may
also vary depending on device insertion/detection time.
Clutter out of tree depends on Cogl's required dependencies via the
pkg-config file. Since Clutter and Cogl moved in tree, it means that
those dependencies need to be checked by Clutter itself, otherwise
headers and libraries won't be found.
ClutterActor should warn if a user tries to add or remove an actor to,
and from, itself on the scene graph.
Clutter will likely crash, or warn way down the line, but if we can make
debugging simpler then we should.
For the GDK backend We're using the GdkDeviceManager API, which maps to
Clutter's own device manager API. GDK has now moved to a per-seat device
management model, and deprecated the device manager singleton one.
In order to avoid the deprecation warnings, we'd have to implement a
model similar to the GDK one inside the generic Clutter API, but that
would also require moving all the others backend to it, which is pretty
pointless.
Instead, we can disable deprecation warnings for the
ClutterDeviceManager implementation inside the GDK backend.
This updates config.h.win32.in to be in-sync with the entries that are in
the config.h.in that is generated by the autotools builds. In particular,
for Visual Studio builds, we default to enable all available drivers ("*").
The function should return true not only if the actor is being painted
by a ClutterClone, but also if it's inside a sub-graph being painted by
a ClutterClone.
https://bugzilla.gnome.org/show_bug.cgi?id=756371
The constrain callback cannot rely on the pointer position of the
corresponding ClutterInputDevice to get the actual delta of the motion
event that is to be constrained since it is only updated when an event is
dispatched. So change the API to pass the previous pointer position when
constraining.
https://bugzilla.gnome.org/show_bug.cgi?id=752752
Compositors need more detailed information about motion events. Make it
possible to retrieve this information when running the evdev backend by
adding the information to the backend specific event struct.
https://bugzilla.gnome.org/show_bug.cgi?id=752752
Since commit 6183eb3632 we disabled swap
throttling in favour of being driven by the GDK frame clock (and thus by
the compositor).
Compositors may decide to unredirect full screen windows to avoid the
performance penalty of the additional copy, especially on X11, which
means that a Clutter application marked as full screen is not going to
be driven by the compositor, and it's not going to be throttled by the
underlying GL machinery. This has a performance impact on constrained
platforms.
For this reason, we should re-enable swap throttling when the window is
full screen.
As the change was introduced especially because of Wayland, we should
check that we're not running as clients under a Wayland compositor; if
we do, we always keep swap throttling disabled, as the compositor will
always manage our output, even when full screen.
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
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
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
There's handlers around relying on up/down/left/right scroll events,
which won't work as expected if only smooth scroll events are sent.
In order to work properly there, we have to retrofit discrete scroll
events on the evdev backend.
Fix this by implementing emission (on devices with a wheel) and
emulation (on anything else) of discrete scroll events. On the former
both smooth and discrete events are set, for the latter we do accumulate
the dx/dy of the latest scroll events, and emit discrete ones when we
accumulated enough. The ending 0/0 event will reset the accumulators for
the next scrolling batch.
https://bugzilla.gnome.org/show_bug.cgi?id=756284
When enable_paint_unmapped is disabled, we shouldn't force the
source widget to be unmapped if the constraints would keep it
mapped; in practice this shouldn't matter unless a paint handler
is messing with the map state.
https://bugzilla.gnome.org/show_bug.cgi?id=745517
Enable animation updates from the GdkFrameClock whenever any timeline is
added to the ClutterMasterClockGdk. This may improve animation
smoothness (depending on the GDK backend in use) because it allows GDK
to tweak its frame timing for animation purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
This is how GdkFrameClock is meant to be used: the frame time is meant
to be queried from the GdkFrameClock within its frame signals, rather
from the system monotonic time source.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
When removing the frame callback on the CoglOnscreen, we loose the ability
to get notified of swap events. This could leave us with a counter != 0
which leads to a deadlock situation after the next realize/draw cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=755014
If we call _clutter_stage_do_update() on a ClutterStage that isn't
mapped/visible, no GL command will be queued, and the Mesa/DRI2
implementation of SwapBuffers will do nothing. This causes
GLX_INTEL_swap_event to not be emitted by the X server because no swapping
has been requested through DRI2 and it eventually leads to a deadlock
situation in ClutterStageCogl because we're waiting for an event before we
start the next draw cycle.
This patch removes the non mapped stages from the list of stages to process.
This is consistent with a previous patch for the ClutterMasterClockGdk [1].
[1] : 5733ad58e5https://bugzilla.gnome.org/show_bug.cgi?id=755014
Setting up the sync_to_vblank in the MasterClock is a bit too late as
the MasterClock can be created after a StageWindow has been created
and realized (and therefore all of its Cogl/GL state setup already).
So move the setup to the backend, prior to any StageWindow creation.
https://bugzilla.gnome.org/show_bug.cgi?id=754938
Clutter still uses part of the deprecated stateful API of Cogl (in
particulart cogl_set_framebuffer). It means Cogl can keep an internal
reference to the onscreen object we rendered to. In the case of
foreign window, we want to avoid this, as we don't know what's going
to happen to that window.
This change sets the current Cogl framebuffer to a dummy 1x1
framebuffer if the current Cogl framebuffer is the one we're
unrealizing.
https://bugzilla.gnome.org/show_bug.cgi?id=754890
We're currently hooked to the "update" signal of the FrameClock. When
embedding Clutter inside GTK+ we want to have the layout phase of GTK+
to notify us the size of our stage.
This patch change to FrameClock signal we're listening to, to the
"paint" signal to make sure we've received the layout information from
GTK+, before painting. Otherwise we paint with a delay of one frame.
https://bugzilla.gnome.org/show_bug.cgi?id=754889
The commit 6cd24faaa5 (actor: Clean up
transform_stage_point()) changed the validation of the transformation
matrix to ignore the fraction part of the determinant. This caused
clutter_actor_transform_stage_point() to fail and return FALSE for
actors which scale was less than 1.
Previously the validation was ('det' being a float):
det = (RQ[0][0] * ST[0][0])
+ (RQ[0][1] * ST[0][1])
+ (RQ[0][2] * ST[0][2]);
if (!det)
return FALSE;
Semantically, the if statement expression '!det' is equivalent to
'det == 0', i.e. 'det == 0.0f'. Post cleanup patches, 'det' was turned
into a double, and the if statement was changed to:
if (CLUTTER_NEARBYINT (det) == 0)
return FALSE;
which, different from before, rounds the determinant to the nearest
integer value, meaning determinant in the range (-0.5, 0.5) would be
considered invalid.
This patch reverts this part to the old behavior, while, because of the
inexact nature of floating point arithmetics, allowing a bit more liberal
meaning of "equals to 0" than '== 0.0'.
https://bugzilla.gnome.org/show_bug.cgi?id=754766
When running on wayland, we might have our own subsurface
desynchronized from the foreign GdkWindow. It is important that we
report the size of the actually surface we're rendering to, otherwise
the logic in ClutterStage might discard resize operation that
resynchronize the subsurface with the stage's size.
https://bugzilla.gnome.org/show_bug.cgi?id=754697
For foreign windows this should be dealt with by the embedding
framework. In particular on Wayland with foreign windows, we might
want to create a subsurface and use the foreign window only for events
and frame clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=754697
Some operations like :
* resize
* show/hide
* set_title
* set_user_resizable
should be handled by the embedding framework, so disable them for
foreign windows.
https://bugzilla.gnome.org/show_bug.cgi?id=754671
When using Clutter embed inside a Gtk application, a stage might end
up realized but not visible. In this case we might discard doing any
kind of animation processing.
https://bugzilla.gnome.org/show_bug.cgi?id=754671
Just like GtkGrid, changing the orientation of a ClutterGridLayout does
not change the existing layout; the orientation property is only used as
a hint when adding new children.
We automatically switch the request mode of the container depending on
the GridLayout's orientation, but we need to keep track of the request
mode during allocation, so that we don't get out of sync if the user
changed the request mode after adding the layout manager.
This change also brings us closer to the code in GtkGrid.
We use the orientation of the grid to get the preferred size of the
layout, but we should be using the orientation of the request instead.
The preferred width has an orizontal orientation, and the preferred
height has a vertical orientation.
This allows us to refactor the get_preferred_* implementation into a
separate function.
We are currently using deprecated/Clutter-specific API in Cogl to
retrieve the XVisualInfo associated with the (E)GLX context. Cogl 1.21.2
added new CoglRenderer API to achieve the same result.
We want to use the Cogl GL3 driver, if possible, and then go through a
known list of Cogl drivers, before giving up and using COGL_DRIVER_ANY.
Based on original patch from Emmanuele Bassi.
We have to create and tear down the whole context when trying
out the drivers though because the extension checks do not happen
until cogl_context_init.
https://bugzilla.gnome.org/show_bug.cgi?id=742678
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.
Certain crossing modes notify about synthesized events, where
the pointer didn't really leave the window. Unsetting the stage
from the device at that time is incorrect, and will leave all
remaining touches unable to pick coordinates, so silently eaten
away.
https://bugzilla.gnome.org/show_bug.cgi?id=750496
Straight from Cogl.
This allows us to propagate the GdkVisual Cogl and Clutter use to
embedding toolkits, like GTK+.
The function is annotated as being added to the 1.22 development
cycle because it will be backported to the stable branch, so that
downstream developers can package up a version of Clutter that does
not crash on nVidia.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
GDK 3.16 started selecting different visuals, to best comply with the
requirements for OpenGL, and this has broken Clutter on GLX drivers that
are fairly picky in how they select visuals and GLXFBConfig.
GDK selects GLXFBConfig that do not include depth or stencil buffers;
Cogl, on the other hand, needs both depth and stencil buffers, and keeps
selecting the first available visual, assuming that the GLX driver will
give us the best compliant one, as per specification. Sadly, some
drivers will return incompatible configurations, and then bomb out when
you try to embed Clutter inside GTK+, because of mismatched visuals.
Cogl has an old, deprecated, Clutter-only API that allows us to retrieve
the XVisualInfo mapping to the GLXFBConfig it uses; this means we should
look up the GdkVisual for it when creating our own GdkWindows, instead
of relying on the RGBA and system GdkVisuals exposed by GDK — at least
on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
In order to do device matching we need to propagate more information,
like the device_id (only on X11 with the XInput2 extension enabled),
the vendor id, and the product id.
https://bugzilla.gnome.org/show_bug.cgi?id=747951
When defining clutter_stage_gdk_update_foreign_event_mask, check for the
same macros as when actually using it.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Its ::gesture-end implementation used to check the press/release
coordinates for the first touchpoint. On multifinger swipes, we
can receive this vfunc called due to other touch sequence going
first, so we'd get 0/0 as the release coordinates for this still
active sequence, resulting in bogus directions.
Instead, check the last event coordinates, that will be always
correct regardless of whether the touchpoint 0 finished yet or
not.
https://bugzilla.gnome.org/show_bug.cgi?id=749739
Commit 79849ef1d5fff9acd310cd68d59df0c7cf2cb28f had a typo in the
device property format check. This property is formated in 8-bit
items, not 32-bit.
This went unnoticed till now because some touchpads were still being
detected as such due to a second check below:
else if (strstr (name, "touchpad") != NULL)
source = CLUTTER_TOUCHPAD_DEVICE;
https://bugzilla.gnome.org/show_bug.cgi?id=749482
It could happen that gdk_screen_get_setting fails to retreive
Gdk/WindowScalingFactor which leads to the following warnings when
clutter_init is called:
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'window-scaling-factor' of type 'gint'
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'dnd-drag-threshold' of type 'gint'
https://bugzilla.gnome.org/show_bug.cgi?id=749256
Slightly edited to fix up whitespace issues.
Edited-by: Emmanuele Bassi <ebassi@gnome.org>
The paint opacity for a top level is always overridden to be the full
value, since it's a composited value and we want to paint our scene.
When clearing the stage framebuffer, though, we want to use the actual
opacity, if ClutterStage:use-alpha is set.
-1 is explicitly an invalid value to pass to eglSwapBuffersWithDamage,
and the specification admits as much:
If
eglSwapBuffersWithDamageEXT is called and <n_rects>, is less
than zero or <n_rects> is greater than zero but <rects> is
NULL, EGL_BAD_PARAMETER is generated.
Fix up our usage of SwapBuffersWithDamage to match the behavior in the
EGL specification.
https://bugzilla.gnome.org/show_bug.cgi?id=745512
These are just terrible API that we've been stringing along since the
0.x days. We cannot truly deprecate them, because they are, in some
cases, the only actual API to perform some operation, and porting all
the code in the world is not going to make us any friends.
For the time being, we use a deprecation notice in the documentation.
The macros are useless for language bindings, and are terribly unsafe
from C as well. There's always the option of using the GObject
properties they refer to, but it's more efficient to just have a simple
getter function.
While each stage has at most a GdkFrameClock, the same GdkFrameClock
instance may drive multiple stages per frame. This means that the
mapping between a GdkFrameClock and a ClutterStage is a 1:M one, not a
1:1.
We should store a list of stages associated to each frame clock
instance, so that we can iterate over it when we need to update the
stages.
This commit fixes redraws of applications using multiple stages,
especially when using clutter-gtk.
_cally_actor_get_top_level_origin() uses a compile time check
without runtime check, which will obviously fail when another
backend like wayland is used.
https://bugzilla.gnome.org/show_bug.cgi?id=746575
When multiple relative motion events are received and queued, we can't
base the relative => absolute motion conversion off of the stage pointer
position, since that is only updated when the queue is processed at
the beginning of each frame. The effect of trying to use the stage
pointer position was that subsequent motion events were effectively
dropped.
To improve things, switch to keeping track of the pointer position
ourselves in the evdev backend and adding to that.
This has the side effect of making the internal function
_clutter_input_device_set_coords not effect the internal coordinate
state of the evdev stage, but AFAICS there is nothing depending on that
so that should be fine.
https://bugzilla.gnome.org/show_bug.cgi?id=746328
There's no point in trying to go ahead if we don't have a context to
create the CoglOnscreen framebuffer, and Cogl will crash anyway if we
pass NULL to the constructor.
With server-side buffer allocation, buffers may be returned out of order
(e.g. they may be held onto by external references or hardware). As such
we may see older buffers the frame after we discard the history from
seeing a very young buffer. To overcome this we want to keep the history
in a ring so we can keep track of older entries without keeping an
unbounded list. After converting to a ring, the maximum buffer age
observed during testing was 5 (expected value of 4), but before we could
see ages as high as 9 due to the huge latency spikes caused by doing full
buffer redraws (compounded by external listeners doing readback on the
damaged areas, for example vnc, drm/udl, prime). For this reason, a
maximum age of 16 was chosen to be suitably large enough to prevent these
worst cases from taxing the system.
v2: Fix off-by-one in combining the damage histroy into the clipping
rectangle, and apply copious whitespace fixes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=745512
References: https://bugzilla.gnome.org/show_bug.cgi?id=724788
References: https://bugzilla.gnome.org/show_bug.cgi?id=669122
cogl provides an interface to pass along damage with the swap buffers
request. This is useful for the display servers and hardware to minimise
the work done in updating the screen and also reducing the work done by
external listeners (such as vnc, drm/udl and PRIME).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=745512
If the rectangle is allocate a size smaller than the border, drawing the
border will end up with negative coordinates, and will mess up the whole
thing. Since rectangles don't have a minimum preferred size, we cannot
rely on the allocation being big enough to contain the border and the
background color.
If the rectangle is smaller than the border width value, we just paint
the border color as well.
Point to ClutterImage, ClutterContent, and ClutterActor where needed, so
that developers trying to port their code will have a chance at figuring
out how.
Nobody has been compiling Clutter with profiling enabled in a long time.
UProf itself hasn't been updated in 5 years, and it still depends on
deprecated components like dbus-glib, with no port to GDBus in sight.
The profiling code was moderately useful in the past, but these days
it's probably better to profile Cogl than Clutter itself; timing
information can be extracted by the timestamp on each diagnostic message
that is now available by default in the CLUTTER_NOTE macro, and we can
add ad hoc counters where needed.
Add clutter_x11_set_use_stereo_stage() that can be called
before clutter_init() so that the CoglDisplay we create and all
stages created from that CoglDisplay will be created with a
stereo fbconfig.
This is done in clutter-x11 because of the similarity to the
existing clutter_x11_set_use_argb_visual(), and because it's
not clear without other examples whether the need to have
stereo enabled from before clutter_init() is universal or
somethign specific to GLX.
Cogl required version is increased to 1.20, which has the
required API.
https://bugzilla.gnome.org/show_bug.cgi?id=732706
Added support for Mir, now clutter can natively draw on MirSurfaces.
This depends on latest cogl git.
Run your clutter apps using CLUTTER_BACKEND=mir
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Toolkits may need to paint actors internally outside the normal tree
(for example to create a shadow shape), in which case they need to
control the opacity directly.
https://bugzilla.gnome.org/show_bug.cgi?id=677412
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The _clutter_stage_update_state() function is currently putting events
into the Clutter event queue. This leads to problems in the gdk
backend because there are assumptions upon the numbers of queued
events, and how many of them should be moved from the main event queue
to the ClutterStages' event queues.
This change triggers the processing of the state update events on the
stage directly, so the main event queue retains the expected number of
events.
https://bugzilla.gnome.org/show_bug.cgi?id=744604
If gdk event retrieval has been disabled and gdk's backend is wayland
we must also disable cogl's wayland event dispatching otherwise cogl
will try to dispatch wayland events itself which blocks the main
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=744058
Pointer button events will be received from a device where a button has
been pressed, even though an equivalent button has been pressed (same
button code) on a device connected to the same seat. notify_button()
expects to only be called as if there was only one pointer device
associated with the given seat, so to achieve this, ignore every event
where forwarding it would result in multiple 'pressed' or 'released'
notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=743615
Keyboard key events will be received from a device where a key has
been pressed, even though an equivalent key has been pressed (same
key code) on a device connected to the same seat. notify_key()
expects to only be called as if there was only one keyboard device
associated with the given seat, so to achieve this, ignore every event
where forwarding it would result in multiple 'pressed' or 'released'
notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=743615
We are checking for Cairo ≥ 1.12 and then do an additional check for the
existence of the cairo_surface_set_device_scale() function because there
were no stable releases of Cairo with it. Now that Cairo 1.14 is out, we
can simply bump up the dependency.
libinput's API changed from separate scroll events for vert/horiz scrolling to
a single event that contains both axes if they changed.
Updated by Armin K. to use the discrete axis value for wheel events as done
in Weston.
https://bugzilla.gnome.org/show_bug.cgi?id=742829
We tried once with commit 398a7ac7 and ended up reverting because of
regressions in the input layer and on Wayland.
We should try again, now that those regressions have been fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=734587
The easing state is part of the AnimationInfo structure, which is stored
inside the GObject's datalist. Each instance frees the data stored there
during finalization, so there is no point for us to restore an easing
state (which may or may not be the last one) just to have everything
cleared out once we chain up to GObject's own finalize() implementation.
Bind the preferred size of an actor using a BindConstraint to the
preferred size of the source of the constraint, depending on the
coordinate of the constraint.
Constraints can only update an existing allocation, which means they
live only halfway through the layout management system used by Clutter;
this limitation makes it impossible, for instance, to query the
preferred size of an actor, if the actor is only using constraints to
manage its own size.
And move the only private ClutterConstraint method to it.
This commit also sneaks in a change that makes sense for the debugging
of the update_allocation() method, which checks if the allocation was
effectively changed.
The core pointer concept doesn't really exist anymore in an XI2 world,
so the clutter API is a bit of a mismatch with what X provides. Using
XIGetClientPointer doesn't really help, as far as i can tell the
semantics of XIGetClientPointer are essentially: Whatever the X server
picked when it had to reply with device-dependant data to a query
without a device specifier. Not very useful...
To make matters worse, whether XIGetClientPointer returns a valid
pointer depends on whether there has been a query that forced it to pick
one in the first place, making the whole thing pretty non-deterministic.
This patch changes things around such that instead of using
XIGetClientPointer to determine the core pointer, we simply pick the
first master pointer device. In practise this will essentially always
be the X virtual core pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=729462
XIGetClientPointer() may return the device id '0' when called early.
This patch makes pointer cursors work in nested mutter Wayland
sessions again.
https://bugzilla.gnome.org/show_bug.cgi?id=729462
The installed header should not have private API declarations and
macros. Let's move those into the uninstalled clutter-backend-osx.h
header file instead.
When merging multiple definitions it's possible that the ObjectInfo
fields may get overwritten. Instead of trampling over the fields, we
should reset them only when they actually change — especially the
"is_actor" one, which controls the destruction of the objects when
unmerging happens.
https://bugzilla.gnome.org/show_bug.cgi?id=669743
We want to recompute the content box when changing the content instance,
in case the preferred size is different and the content gravity uses the
preferred size; the change of content with different preferred size and
same gravity should also trigger an implicit transition.
https://bugzilla.gnome.org/show_bug.cgi?id=711182
Some actors want to have a preferred size driven by their content, not
by their children or by their fixed size.
In order to achieve that, we can extend the ClutterRequestMode
enumeration so that clutter_actor_get_preferred_size() defers to the
ClutterContent's own preferred size.
https://bugzilla.gnome.org/show_bug.cgi?id=676326
An easing mode can be set on a frame of a KeyframeTransition.
However, the progress value of the current frame is computed using using
a linear function.
This patch adds a call to clutter_easing_for_mode() to compute
the actual progress value.
Note that parametrized easing modes (bezier and 'step') are not taken
into account.
https://bugzilla.gnome.org/show_bug.cgi?id=740997
If a touchpad is not multitouch, or does not report MT axes (eg. through
the libinput driver), resort to name matching before falling back to
CLUTTER_POINTER_DEVICE.
https://bugzilla.gnome.org/show_bug.cgi?id=741350
In keyboard/mouse wireless combos, it is rather common for the mouse to
claim it contains the multimedia keys, this makes libinput enable both
the pointer and keyboard capabilities on this device, and Clutter thus
to create a keyboard ClutterInputDevice for it.
Ideally clutter devices should be able to reflect their full capabilities,
or maybe account for the fact that certain events can be sent from
seemingly unexpected device types. But this will bring a somewhat better
behavior on such devices.
https://bugzilla.gnome.org/show_bug.cgi?id=740518
Atlasing is fine for smaller textures, but once they get too large its
downsides outweight the benefits. At worst, the larger texture will end
up inside its own atlas, but at worst it will require copying and/or
resizing of an existing atlas.
The cut-off at 512x512 pixels is a bit arbitrary, and we can change it
at any point; it would be nice if we could get the texture limit from
Cogl, and then use a fraction of that size as the cut-off limit. Sadly,
that's not portable, and it's not guaranteed to work either.
For a variety of complicated reasons, ClutterText currently sets fields
on the PangoContext when creating a layout. This causes ClutterText to
behave somewhat erratically in certain cases, since the PangoContext is
currently shared between all actors.
GTK+ creates a PangoContext for every single GtkWidget, so it seems like
we should do the same here.
Move the private code that was previously in clutter-main.c into
clutter-actor.c and clean it up a bit. This gives every actor its own
PangoContext it can mutilate whenever it wants, at its heart's content.
https://bugzilla.gnome.org/show_bug.cgi?id=739050
clutter_set_font_flags already calls clutter_backend_set_font_options,
which emits a signal which our PangoContext listens to, so this is just
duplicate and unneeded code.
https://bugzilla.gnome.org/show_bug.cgi?id=739050
libinput_suspend() will trigger the removal of input devices, but also
the emission of button/key releases pairing everything that is pressed
at that moment. These events are queued, but the ClutterInputDevice
pointers in these will point to invalid memory at the time these are
processed.
Fix this by flushing the event queue, in order to ensure there are no
unprocessed input events after libinput_suspend().
https://bugzilla.gnome.org/show_bug.cgi?id=738520
Just like unmapped children.
Apparently, layers above Clutter allow mapped children without an
allocation, instead of unmapping them. This means we need to ignore
them when computing the paint volume.
Patch originally by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=736682
To support sub-pixel motion events coming from relative events, the
fraction part needs to be stored in the input device state as well. To
do this, simply change the current type from gint to gfloat.
https://bugzilla.gnome.org/show_bug.cgi?id=736413
If gtk_init is called after clutter_init, it can override clutter
AtkUtil implementation. In that situation, we can't say that
the accessibility is enabled, as the root object would be wrong.
In order to provide a way to prevent this:
* clutter_get_accessibility_enabled returns true of false
depending on the current AtkUtil implemented
* cally_accessibility_init always override AtkUtil implementation.
The get_threshold_tigger_egde() method was renamed to fix the typo, but
it obviously broke the ABI. To be fair, nobody in the whole of Debian
was using the symbol, apparently, so it's not like we broke existing
code. Still, it's not nice to break ABI without bumping soname, so let's
put the old symbol back in — obviously, deprecated — as a wrapper to the
newly added one.
If the device manager is created and queried for the client pointer at
a very early stage in application lifetime, the device_id returned would
be 0 as the server hasn't apparently decided yet about the client pointer.
For these situations, doing XSync prior to fetching the client pointer
gets the server to device about the client pointer before we query it.
https://bugzilla.gnome.org/show_bug.cgi?id=735388
When an application sets the scaling factor manually we should mark it as fixed
and not override it when the xsettings change. This matches GDKs behaviour.
In order for this to work we cannot use the same path when setting the value
internally so introduce a _clutter_settings_set_property_internal and use it
for that.
https://bugzilla.gnome.org/show_bug.cgi?id=735244
We need to release the temporary reference we acquired in order for the
signal emission to work.
https://bugzilla.gnome.org/show_bug.cgi?id=734761
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
This reverts commit 398a7ac713.
We cannot really use the GDK backend without massive regressions inside
the input layer, like touch events and gestures. The GDK backend is not
entirely up to scratch, and it's late in the cycle.
Let's land this early in 3.15, and get it up to par with X11.
Quite a few people at Guadec complained of pinpoint being broken in
speaker+fullscreen mode, with slides being half displayed. It turns
out that the X11 backend of clutter was being used and this backend
assumes the size of the current monitor is the size of the X screen
(that's not the case with multiple monitors).
To work around the shortcomings of the X11 backend we should probably
position the GDK one before. GDK implements most of the logic the
ClutterStage needs and is probably more tested.
https://bugzilla.gnome.org/show_bug.cgi?id=734587
To get correct premultiplied opacity on a canvas content, white needs
to be assigned to the color that is passed to the texture node. The
content will be very dark for lower opacity values otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=733385
xkb_state creation has been refactored out of clutter_evdev_set_keyboard_map(),
and used too in clutter_evdev_reclaim_devices(), so the xkb_state is fresh
clean after input is paused/resumed (and keyboard state possibly changed in
between)
https://bugzilla.gnome.org/show_bug.cgi?id=733562
There may be odd situations where full gesture cancellation may be wanted at once
when the first touch is lifted and ::gesture-end is emitted on a gesture action.
Although calling clutter_gesture_action_cancel() within the ::gesture-end handler
causes 2 critical warnings that are otherwise harmless.
https://bugzilla.gnome.org/show_bug.cgi?id=732907
clutter_stage_set_paint_callback() has the disadvantage that it only
works for a single caller, and subsequent callers will overwrite and
break previous callers. Replace it with an ::after-paint signal that is
emitted at the same point - after all painting for the stage is
completed but before the drawing is presented to the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=732342
CLUTTER_ENTER/LEAVE might be processed too, leading to accounting of the
NULL sequence (ie. pointer) in the gesture, and fooling the gesture with
a static extra point that wouldn't go away.
https://bugzilla.gnome.org/show_bug.cgi?id=732235
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
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
In situations when the default backend would fail (for example
when compiled with X11 support but run without DISPLAY), or
when the application is using backend specific code, it makes
sense to let the application choose the backend explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=707869
It was a bad idea to add it, because clutter events are batched,
so by the time the application processes one, the keyboard state
internally tracked by clutter could be already different.
Instead, apps should use clutter_event_get_state_full()
https://bugzilla.gnome.org/show_bug.cgi?id=706494
We can't dispatch a motion event for EV_REL (because we don't
have yet the other half of the event), but we can't also queue
them at the end of processing (because we may lose some history
or have button/keys intermixed).
Instead, we use EV_SYN, which means "one logical event was
completed", and let the winsys-independent code do the actual
motion compression.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
When we release a device, we lose all the events after that point,
so our state can become stale. Similarly, we need to sync the
state with the effectively pressed keys when we reclaim.
This ensures that modifier keys don't get stuck when switching
VTs using a keybinding.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
When talking to other applications or serializing the modifier
state (and in particular when implementing a wayland compositor),
the effective modifier state alone is not sufficient, one needs
to know the base, latched and locked modifiers.
Previously one could do with backend specific functionality
such as clutter_device_manager_evdev_get_xkb_state(), but the
problem is that the internal data structures are updated as
soon as the events are fetched from the upstream source, but
the events are reported to the application some time later,
and thus the two can get out of sync.
This way, on the other hand, the information is cached in the
event, and provided to the application with the value that
was current when the event was generated.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
These two devices are logically tied togheter, and their state
should always be the same. Also, we need to update them after
the event is queued, as the current modifier state (as opposed to the
modifier mask in the event) should include also the effect of the last
key press/release.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
Add a new callback that is called prior to emitting pointer
motion events and that can modify the new pointer position.
The main purpose is allowing multiscreen apps to prevent the
pointer for entering the dead area that exists when the screens
are not the same size, but it could also used to implement
pointer barriers.
A callback is needed to make sure that the hook is called early
enough and the Clutter state is always consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=706652
If we don't get passed a CoglFramebuffer when creating the root paint
node then we ask Cogl to give us the current draw buffer.
This allows the text-cache conformance test to pass, but it'll require
further investigation.
Currently the default values according to their param spec don't
match the actually used defaults, so update the former to reflect
the actual behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Whether a child should receive extra space should be determined
by the expand property, not [xy]_fill (which just determine how
additional space should be used). The behavior is already correct
when using the ClutterActor:[xy]_expand properties, but needs
fixing for the corresponding ClutterBoxLayoutChild property.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Just as BoxLayout, BinLayout uses an odd interpretation of the box
passed into allocate(): to define a child area of (w x h) starting at
(x, y), callers need to pass a box of (x, 2 * x + w, y, 2 * y + h).
This behavior is just confusing, change it to use the full box for
child allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Currently, BoxLayout interprets the box passed into allocate() in
a fairly peculiar way:
- in the direction of the box, all space between [xy]1 and [xy]2
is distributed among children (e.g. children occupy the entire
width/height of the box, offset by [xy]1)
- in the opposite direction, expanded children receive space
between [xy]1 and the height/width of the box (e.g. children
occupy the width/height of the box minus [xy]1, offset by [xy]1)
The second behavior doesn't make much sense, so adjust it to interpret
the box parameter in the same way as the first one.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
The implicitly created transitions are removed when complete by the
implicit transition machinery. The remove-on-complete hint is for
user-provided transitions.
https://bugzilla.gnome.org/show_bug.cgi?id=705739
ClutterTransition:remove-on-complete uses the ClutterTimeline::stopped
signal, as it's the signal that tells us that the timeline's duration
has fully elapsed.
Mouse wheel events come as EV_REL/REL_WHEEL, and we can convert
them to clutter events on the assumption that scrolling with
the wheel is always vertical.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
xkb_state_update_key() needs to be called only on state transitions,
otherwise the state tracking gets confused and locks certain modifiers
forever.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
A wayland compositor needs to have more keyboard state than
ClutterModifierState exposes, so it makes sense for it to use
xkb_state directly. Also, it makes sense for it to provide
it's own keymap, to ensure a consistent view between the compositor
and the wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
All evdev devices are slave devices, which means that xkb state
and pointer position must be shared by emulating a core keyboard
and a core pointer. Also, we must make sure to add all modifier
state (keyboard and button) to our events.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
Hardware keycodes in Clutter events are x11 keycodes, which are
the same as evdev + 8, but we need to reverse the translation when
explicitly asked for an evdev keycode.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
In some cases, applications (or actually, wayland compositors)
don't have the required permissions to access evdev directly, but
can do so with an external helper like weston-launch.
Allow them to do so with a custom callback that replaces the regular
open() path.
https://bugzilla.gnome.org/show_bug.cgi?id=704269
This is necessary to avoid a deadlock with the compositor. When setting
a stage size before the stage was shown this would trigger a redraw
inside clutter_stage_wayland_resize. This redraw would result
in a call into eglSwapBuffers which would attach a buffer to the surface
and commit. Unfortunately this would happen before the role for the
surface was set. This would result in the compositor not relaying to the
client that the desired frame was shown.
With this change the call to wl_shell_surface_set_toplevel is always
made before the first redraw.
https://bugzilla.gnome.org/show_bug.cgi?id=704457
We should not create a shell surface and set the role for that shell
surface if the surface was a foreign one provided through
clutter_wayland_set_wl_surface
https://bugzilla.gnome.org/show_bug.cgi?id=699578
This adds support for optionally a providing a foreign Wayland surface
to a ClutterStage before it is first show. Setting a foreign surface
prevents Cogl from allocating a surface and shell surface for the stage
automatically.
v2: add CLUTTER_AVAILABLE_IN_1_16 annotation and API reference docs
(review from Emmanuele Bassi)
v3: set a boolean to indicate that this stage is using a foreign surface
(Rob Bradford)
https://bugzilla.gnome.org/show_bug.cgi?id=699578
This allows the integration of Clutter with another library, like GTK+,
that is dispatching the events itself. This is implemented by calling
into the cogl_wayland_renderer_set_event_dispatch_enabled() and since
that function must be called on the newly created renderer the newly
added clutter_wayland_disable_event_retrieval must be called before
clutter_init()
https://bugzilla.gnome.org/show_bug.cgi?id=704279
Since commit 4543ed6ac3 in Cogl, Cogl will now try to consume
Windows message itself. This doesn't really cause any problems because
both message loops just call DispatchMessage which will cause the
message to be routed through Clutter's window procedure either way.
However, it's not great to have two sources listening for messages so
this patch disables Cogl's message retrieval.
https://bugzilla.gnome.org/show_bug.cgi?id=701356
This removes a bit of work that we have to do for every device, and makes it
easy for mutter to patch out parts of the event mask it doesn't want.
https://bugzilla.gnome.org/show_bug.cgi?id=703969
The Wayland 1.0 API allows orthoganal components of an application to
query the shell and compositor themselves by querying their own
wl_registry. The corresponding API in Cogl has been removed so Clutter
shouldn't call it anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=703878
The Wayland server API has changed so that wl_shm_buffer is no longer
a type of wl_buffer and wl_buffer will become an opaque type. This
changes ClutterWaylandSurface to accept resources for a wl_buffer
instead of directly taking the wl_buffer so that it can do different
things depending on whether the resource points to an SHM buffer or a
normal buffer. This matches similar changes to Cogl:
https://git.gnome.org/browse/cogl/commit/?id=9b35e1651ad0e46ed48989https://bugzilla.gnome.org/show_bug.cgi?id=703608
Cogl 1.16 has deprecated a lot of API which it will be difficult for
Clutter to catch up with. For the time being the warnings are just
being disabled to keep the build output clean.
https://bugzilla.gnome.org/show_bug.cgi?id=703877
There is no reasonable use case for having the functions, the virtual
functions, and the signals for realization and unrealization; the
concept belongs to an older era, when we though it would have been
possible to migrate actors across different GL contexts, of in case a GL
context would not have been available until the main loop started
spinning. That is most definitely not possible today, and too much code
would utterly break if we ever supported that.
The majority of Clutter input events require a time so that that the
upper levels of abstraction can identify the ordering of events and also
work out a click count.
Although some Wayland events have microsecond timestamps not all those
that Clutter expects do have. Therefore we would need to create some
fake times for those events. Instead we always calculate our own time
using the monotonic time.
https://bugzilla.gnome.org/show_bug.cgi?id=697285
If we allow content repeats on the texture nodes, then we need to use
the "automatic" wrap mode for the texture layer in the pipeline, instead
of the clamp-to-edge one.
Reported-by: Matthew Watson <matthew@endlessm.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
This reverts commit 6dd9da05c7.
Windowing system features we need are not mapped on cogl_has_feature().
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Cogl (as of 0b2b46ce) now only sets the shell surface as toplevel when
the CoglOnscreen is shown.
Without calling wl_shell_surface_set_toplevel the compositor will not
know what role to give to the compositor and thus the stage will not
appear.
When we look to support multiple roles / foreign surfaces we will need
to revisit this call and ensure we only call it when we are working in
the default case.
https://bugzilla.gnome.org/show_bug.cgi?id=703188
Since Cogl also polls on this file descriptor we can get into situations
where our event source is woken up to handle events but those events
have instead been handled by Cogl resulting in the source sitting in
poll().
We can safely rely on Cogl to handle the polling on the event source and
to dispatch those events.
https://bugzilla.gnome.org/show_bug.cgi?id=702202
When the cursor visibility changes, we have to relayout the ClutterText
actor instead of just redrawing it - as the cursor changes the
PangoLayout size, a size request cycle is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=702610
While we still don't want to perform implicit transitions on unmapped
actors, we can relax the requirement on having been painted once; the
was_painted flag was introduced to avoid performing implicit transitions
on the :allocation property, but for that we can use the
needs_allocation flag instead, as needs_allocation will be set to FALSE
when we have been painted as well.
Thus, we retain our original goal of not having actors "flying" into
position on their first allocation, without the side effect of
preventing animations when emitting the ::show signal.
When setting the font using clutter_text_set_font_description(), the
font settings on a ClutterText actor can be reset when there is a dpi
changes signaled by the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=702016
1ddef9576d87c98fafbcefe3108f04866630c2cd had its logic the
wrong way round, a gesture should begin as soon as the requested number
of touchpoints is reached. Correcting this fixes tap events
https://bugzilla.gnome.org/show_bug.cgi?id=700980
When we changed the MetaGroup to handle internal effects, we updated
has_effects(), but forgot to fix the equivalent has_constrains() and
has_actions() method.
Now, if we clear the constraints or the actions on an actor, and we
call has_constraints() or has_actions(), we get an false positive.
When using a ClutterOffscreenEffect, the size of the offscreen buffer
allocated to perform the effect is currently computed using the paint
volume of the actor it's attached to and in the case the paint volume
cannot be computed, the effect falls back to using the stage's size.
If you scale an actor enough so its paint volume is much bigger that
the size of the stage, you can end up running out of memory (which
leads to your application crashing).
https://bugzilla.gnome.org/show_bug.cgi?id=699675
The "should this implicit transition be skipped" check should live into
its own function, where we can actually explain what it does and which
conditions should be respected.
Instead of just blindly skipping actors that are unmapped, or haven't
been painted yet, we should add a couple of escape hatches.
First of all, we don't want :allocation to be implicitly animated until
we have been painted (thus allocated) once; this avoids actors "flying
in" into their allocation.
We also want to allow implicit transitions on the opacity even if we
haven't been painted yet; the internal optimization that we employ in
clutter_actor_paint() and skips painting fully transparent actors is
exactly that: an internal optimization. Caller code should not be aware
of this change, and it should not influence code outside of ClutterActor
itself.
The rest of the conditions are the same: if the easing state's duration
is zero, or if the actor is both unmapped and not in a cloned branch of
the scene graph, then implicit transitions are pointless, as they won't
be painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698766
This should actually ensure that the calculations of the Z translation
for the projection matrix is resolved to "variable * CONSTANT". The
original factors are left in code so it's trivial to revert to the
trigonometric operations if need be, even without reverting this commit.
The ClutterActor::paint signal is deprecated, and connecting to it even
to get notifications will disable clipped redraws because of violations
of the paint volume.
The only actual valid use case for notifications of a successful frame
is on the ClutterStage, so we should add new (experimental) API for it,
so that users can actually subscribe to it — at least if you're writing
a compositor.
Shoving a signal in a performance critical path is not an option, and
I'm not sure I want to commit to an API like this yet. I reserve the
right to revisit this decision in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=698783
Currently, clutter_canvas_set_size() causes invalidation of the canvas
contents only if the newly set size is different. There are cases when
we want to invalidate the content regardless of the size set, but we
cannot do that right now without possibly causing two invalidations,
for instance:
clutter_canvas_set_size (canvas, new_width, new_height);
clutter_content_invalidate (canvas);
will cause two invalidations if the newly set size is different than
the existing one. One way to work around it is to check the current
size of the canvas and either call set_size() or invalidate() depending
on whether the size differs or not, respectively:
g_object_get (canvas, "width", &width, "height", &height, NULL);
if (width != new_width || height != new_height)
clutter_canvas_set_size (canvas, new_width, new_height);
else
clutter_content_invalidate (canvas);
this, howevere, implies knowledge of the internals of ClutterCanvas,
and of its optimizations — and encodes a certain behaviour in third
party code, which makes changes further down the line harder.
We could remove the optimization, and just issue an invalidation
regardless of the surface size, but it's not something I'd be happy to
do. Instead, we can add a new function specifically for ClutterCanvas
that causes a forced invalidation regardless of the size change. If we
ever decide to remove the optimization further down the road, we can
simply deprecate the function, and make it an alias of invalidate()
or set_size().
Since we are trying to eliminate the ClutterGeometry type, we should
replace the only entry point still using it: the ::cursor-event signal
of ClutterText.
Instead of passing the cursor geometry, we should add an accessor
function.
The combination of signal and getter for the cursor geometry means that
we can deprecate ClutterText::cursor-event, and mark it for removal in
Clutter 2.0.
https://bugzilla.gnome.org/show_bug.cgi?id=682789
On the other backends we will get some sort of expose event after
showing the stage's window which will queue a redraw. These expose
events don't exist on Wayland so nothing will cause Clutter to queue a
redraw. Weston doesn't bother displaying anything for the stage's
surface until the first buffer is sent, which of course it will never
receive if Clutter doesn't paint anything. This patch just makes it
explicitly queue a redraw after the stage is shown so that we will
always pass at least one frame to the compositor.
The bug can be seen by running test-stage-sizing. That example doesn't
have any animations so it won't try to queue any redraws until
something interacts with it. On the other hand something like
test-actors works fine without the patch because it constantly queues
redraws anyway in order to display the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=696791
If clutter is built with both X11 and Wayland support, prefer the
(more complete for now) X11 backend. This matches GTK+'s current
ordering.
This allows distributions to ship a clutter version with both backends
built, and using an envvar to switch to the wayland backend and test
applications.
In the future, applications would be able to choose which backend
they prefer and in which order.
https://bugzilla.gnome.org/show_bug.cgi?id=695838
If an actor has not been painted yet, or it's not going to be painted,
we can ignore transitions queued on it.
By ignoring transitions on actors that have not been painted yet, we can
avoid doing work during the set up phase of the scene graph, as well as
avoiding actors "flying in" from nowhere.
Obviously, we have to take into account potential clones, so we need to
check that the actor is not part of a cloned branch of the scene graph,
as well as checking if the actor has mapped clones.
If an actor is unmapped then it won't be painted, so we can safely
short-circuit out of _clutter_actor_queue_redraw_full() if the mapped
flag is not set.
We need, on the other hand, make an exception for Clones, otherwise
they won't receive notification that the source actor has changed
and they won't be painted.
This allows us to ignore redraws queued on children of invisible
parents, and avoid traversing the scene graph.
Instead of using signal notifications, we should be able to keep track
of the clones of an actor from within ClutterActor itself, using private
API. There's no point in pretending that people can actually create a
Clone class out of tree, given the amount of invariants we have to punch
through in order to implement a proper replicator node of the scene
graph, so we can just skip the signal emissions and just do the right
thing at the right time.
More comments are warranted: these functions are pretty much full of
potential side effects, and I'd really like to avoid keeping everything
in my head forever.
Along with the comments and the type casting reduction, I sneaked in a
one line change that is clearly correct after reading the flow of the
whole thing: we queue only a relayout after three potential redraws have
been queued. If we manage to miss a redraw and yet still get a relayout
then it means that most of our assumptions are fundamentally wrong, and
that we ought to dump this whole business of computer programming, and
just go back to being a hunter-gatherer species.
Since XIQueryVersion, the bad API that it is, chooses the first client
version that it gets, we need to ensure that we pass XIQueryVersion the
new XI2.3 version, knowing fully well that Clutter won't be confused
by the new features.
https://bugzilla.gnome.org/show_bug.cgi?id=692466
The X server should fill in the minor version that it supports in the
case where it only supports the older version. We should not get a
BadRequest or fail the version check if we pass something higher.
https://bugzilla.gnome.org/show_bug.cgi?id=692466
Text exposed by the AtkText methods should be the text
displayed to the user (like the internal method
clutter_text_get_display_text). So it should use the password-char
if it is being used.
This is also a security concern.
The original code inside ClutterActor that dealt with Transitions
stopping was written for the ::completed signal, thus the code was
correctly handling the lifetime of the instances; when we moved to the
::stopped signal, we assumed that it worked in the same way - with less
conditions to be checked, obviously, but fundamentally similar to the
::completed signal. Sadly, I screwed up the signal definition, and the
signal ended up calling our handlers, but not the default one that did
the cleanup and released references on the Animatable instance.
After fixing the Timeline::stopped signal, we can go back to the
previous code.
Thanks to Craig Hughes for the help in tracking down this mess.
https://bugzilla.gnome.org/show_bug.cgi?id=695158
A copy and paste thinko: the ::stopped signal is using the
ClutterTimelineClass.completed slot instead of the .stopped one,
thus preventing sub-classes of ClutterTimeline from overriding the
signal's default closure.
When stopping the transition we need to release the reference we
maintain while removing the Transition from the hash table inside an
actor. If we fail to do so, the Transition is never released, which
means we leak the Animatable instance we tied to it.
https://bugzilla.gnome.org/show_bug.cgi?id=695158
The ClutterOffscreenEffect.get_target_size() method has been deprecated,
and replaced by the get_target_rect() one. We can easily switch to the
latter, and avoid the deprecation warning.
https://bugzilla.gnome.org/show_bug.cgi?id=670004
The target size is not always enough, there are cases where the offset
used to paint the target must also be available for developers
implementing an OffscreenEffect.
The get_target_rect() method returns the rectangle used to paint the
target, with the offsets in the ClutterRect:origin and the texture size
in the ClutterRect:size fields, respectively.
The get_target_size() method should be deprecated, given that its
replacement is generally more useful.
https://bugzilla.gnome.org/show_bug.cgi?id=670004
If we pass TRUE for x_align and FALSE for y_align, the full available
width should be passed to clutter_get_preferred_height, and the same
should be true in the other dimension.
https://bugzilla.gnome.org/show_bug.cgi?id=694237
Instead of directly accessing the instance fields. This removes a
compiler warning after the constification of g_get_prgname(), and it
seems to me to be generally more correct.
Instead of using a custom apply_transform(), paint(), and pick()
implementations, we can simply apply a transformation to the children of
a ScrollActor.
https://bugzilla.gnome.org/show_bug.cgi?id=686225
As wayland-client.h and wayland-server.h can't be included together,
split the Wayland backend file into clutter-backend-wayland.h, which
only defines the types, and clutter-backend-wayland-priv.h, which
actually uses the Wayland client types.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692851
The definition of wl_display differs between Wayland clients and
servers, and it's unsafe to include both wayland-client.h and
wayland-server.h at the same time. Fudge around this by making the
compositor public API use void * rather than struct wl_display *.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692851
This function is deprecated and has been replaced by set_display() on
the renderer. This is done in the get_renderer() vfunc of both the x11
and gdk backends already.
Actually cogl_xlib_set_diplay() is now a no-op and can be safely removed.
https://bugzilla.gnome.org/show_bug.cgi?id=687652
Being able to set a marker at a normalized point on a timeline, instead
of using a specific time, is a nice fit with the current Timeline class
API.
https://bugzilla.gnome.org/show_bug.cgi?id=694319
If anything in the system changes the config for fontconfig then an
XSetting will be set to record the last timestamp of the config file.
This is presumably so that applications can be notified that it has
changed and can reload the configuration. However once this setting is
set it will remain set for the lifetime of the X server. This causes
Clutter to handle the setting during the initialisation of the
backend. Previously this would cause problems because Clutter would
end up creating the default PangoFontMap before the backend has
created the CoglContext. The PangoFontMap would in turn cause the
default CoglContext to be created. Clutter will then later create its
own CoglContext which means there will be two and the first one will
be leaked. Cogl currently can't really cope with multiple contexts
being created so it falls apart.
This patch fixes it to skip reloading the config for fontconfig if
there isn't a default font map yet. The config will presumably
naturally be read with the latest values when it is finally created
anyway so it doesn't need to be read immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=693696
New experimental API is added to allow changing the way that redraws
are timed for a stage to include a "sync delay" - a period after
the vertical blanking period where Clutter simply waits for updates.
In detail, the algorithm is that when the master clock is restarted
after drawing a frame (in the case where there are timelines running)
or started fresh in response to a queued redraw or relayout, the
start is scheduled at the next sync point (sync_delay ms after the
predicted vblank period) rather than done immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=692901
In commit 8f4e39b6d7 the Wayland code was updated to use the new
xkbcommon API. This involved changing the common XKB code shared with
the evdev input backend. However the evdev input backend was not
modified so it wouldn't compile. This patch just makes a minor change
to update it.
https://bugzilla.gnome.org/show_bug.cgi?id=693348
Use the buffer_age extension when available to recycle backbuffer contents
instead of blitting from the back to front buffer when doing clipped redraws.
The picking is now done in a pixel that is going to be repaired during the next
redraw cycle for non static scences.
This should improve performance and avoid tearing.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
This allows us to report to the backend that the stage's back buffer has been trashed
while handling picking. If the backend is keeping track of the contents of back buffers
so it can minimize how much of the stage is redrawn then it needs to know when we do pick
renders so it can invalidate the back buffer.
Based on patch from Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
The behaviour imitates GtkEntry and ignores attributes from markup because Pango
barfs on invalid markup. Also add an example to the text-field interactive test.
https://bugzilla.gnome.org/show_bug.cgi?id=686477
As x11 considers num lock and scroll lock to be modifiers, code that
checks for an exact modifier combination will fail if naively done when
num lock or scroll lock are turned on. Applications that want to ignore
these modifiers will need to use XKB to manually mask out the modifier
state.
As it is very unlikely that applications will want to care about the
state of num lock or scroll lock for key press/key release events, mask
out the num lock and scroll lock keys automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=690664
This has been disabled since February 2008, on the grounds that XFixes
didn't work reliably for hiding cursors. This has almost certainly been
fixed then and seems to work entirely reliably across a number of X
servers released in the past few years, and is definitely better than a
1x1 black dot for a cursor.
Helpfully though, where the spec states that the cursor will be hidden
when inside the specified window or one of its children, it actually
only uses the window to look up the Screen, and hides the cursor across
the entire Screen. So, when using this, we also need to track crossing
events.
If it's still broken, this needs to be fixed in the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=690497
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The _clutter_process_event() function may get called while already
servicing a _clutter_process_event() invocation (eg. when generating
ENTER events before emitting TOUCH_BEGIN).
In these cases clutter_get_current_event() would return NULL after
the inner call to _clutter_process_event() has finished, thereafter
making the current event inaccessible during the remaining portion
of the outer event emission.
By stacking the current events in ClutterMainContext instead of
simply replacing them we do not lose track of the real current event.
Also update clutter_get_current_event_time() to be consistent from a
reentrancy perspective.
https://bugzilla.gnome.org/show_bug.cgi?id=688457
Instead of placing the whole body of the function inside an if block,
let's make it clear what each part of the function does. Also, add more
comments.
GLib 2.36 will deprecate g_type_init() in favour of automatic
initialization through a constructor function. We need to add the
version check to avoid a compiler warning.
When setting an explicit transform with clutter_actor_set_transform()
and a non (0,0) pivot-point, clutter_actor_apply_transform() will fail
to roll back the pivot-point translation done before multiplying the
transformation matrix due to the "out:" label being slightly misplaced
in clutter_actor_real_apply_transform().
This works properly:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_actor_set_rotation_angle (actor, CLUTTER_Z_AXIS, 30);
This results in the actor being moved to the pivot-point position:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_matrix_init_identity(&matrix);
cogl_matrix_rotate (&matrix, 30, 0, 0, 1.0);
clutter_actor_set_transform (actor, &matrix);
This also add a conformance test checking that even when using a
pivot-point, no matter how a rotation is set the resulting
transformation matrix will be the same.
https://bugzilla.gnome.org/show_bug.cgi?id=690214
clutter_actor_allocate_preferred_size is supposed to use the fixed
position of an actor. Unfortunately, recent refactorings made it so
that it accidentally used the current allocation. As the current
allocation may be adjusted by the actor, or have been previously
allocated in a strange spot, it may have unintended side effects. Use
the fixed positioning of the actor instead.
This fixes weird issues with margins colliding with
ClutterFixedLayout, causing strange offsets on relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=689316
The documentation said that you should return TRUE to mark
that the action was handled, but the code did the reverse.
Change the documentation to reflect what all the other gestures
do.
https://bugzilla.gnome.org/show_bug.cgi?id=689061
Otherwise, we'll have incorrect scrolling when we switch hardware
devices without switching virtual devices. For example, on a ThinkPad,
scroll using the touchpad, move the eraser mouse, and then scroll again:
the deltas will be wrong. This also matches what GTK+ does.
https://bugzilla.gnome.org/show_bug.cgi?id=689258
When trying to clamp to pixel a box that is exactly in between 2
pixels, the clutter_actor_box_clamp_to_pixel() function changes the
size of the box.
Here is an example :
ClutterActorBox box = { 10.5, 10, 20.5, 20};
g_message ("%fx%f -> %fx%f", box.x1, box.y1, box.x2, box.y2);
clutter_actor_box_clamp_to_pixel (&box);
g_message ("%fx%f -> %fx%f", box.x1, box.y1, box.x2, box.y2);
Here is what you get :
** Message: 10.500000x10.000000 -> 20.500000x20.000000
** Message: 10.000000x10.000000 -> 21.000000x20.000000
That is because of the properties of the ceilf and floorf function
used to do the clamping.
For example, ceil(0.5) is 1.0, and ceil(-0.5) is 0.0.
And, floor(0.5) is 0.0, and floor(-0.5) is -1.0.
To work around that problem this patch retains the distance between x
and y coordinates and apply that difference before calling ceilf() on
x2 and y2.
https://bugzilla.gnome.org/show_bug.cgi?id=689073
Export the last event received for each touch point in its entirety,
instead of duplicating ClutterEvent accessors one at a time.
examples/pan-action.c has been updated to show the type of the event
that's causing the panning.
https://bugzilla.gnome.org/show_bug.cgi?id=685737
TapAction is a GestureAction-subclass that handles clicks and
tap gestures. It is meant to provide a replacement for ClickAction
using GestureAction:
• it handles events trasparently without capturing them, so that it
can coexists with other GestureActions;
• the ::tap signal is not emitted if the drag threshold is exceeded;
• building upon GestureAction the amount of code is greatly reduced.
TapAction provides:
• tap signal, notifying users when a tap has been performed.
The image-content example program has been updated replacing its
ClickAction usage with TapAction.
https://bugzilla.gnome.org/show_bug.cgi?id=683948
Ensure that when cancelling a gesture, either because a callback
has returned FALSE or because clutter_gesture_action_cancel() has
been called, the array tracking touch points is emptied and a whole
new set of touch points is needed before restarting the gesture.
https://bugzilla.gnome.org/show_bug.cgi?id=685221
Let gesture subclasses override how the drag threshold should
be handled:
• CLUTTER_GESTURE_TRIGGER_NONE tells GestureAction that the gesture
must begin immediately and there's no drag limit that will cause
its cancellation;
• CLUTTER_GESTURE_TRIGGER_AFTER is the default GestureAction behaviour,
where it needs to wait until the drag threshold has been exceeded
before considering the gesture valid;
• CLUTTER_GESTURE_TRIGGER_BEFORE will make GestureAction cancel
the gesture once the drag exceed the configured threshold.
For example, ZoomAction and RotateAction could set
CLUTTER_GESTURE_TRIGGER_NONE since the use of two fingers makes the
begin of the action more self-evident, while an hypothetical Tap
gesture may use CLUTTER_GESTURE_TRIGGER_BEFORE to cancel the tap if
the pointer moves too much.
https://bugzilla.gnome.org/show_bug.cgi?id=685028
The code for handling key repeats (and in particular stopping on focus loss)
assumes that the repeat key is set to XKB_KEYCODE_INVALID in the default case.
This change switches to the new mechanism for loading a cursor into a buffer.
It no longer relies on having a PNG stored in a known location and instead
loads from the Wayland cursor theme.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Add support for repeating keys to the Wayland input backend.
Unfortunately the repeat delay/interval is hardcoded into the Clutter
backend, as Wayland doesn't yet tell clients what the global values
should be.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For Wayland, this is mostly the input protocol having changed, although
there's also the SHM pool API, the cursor API, as well as fullscreen and
ping.
Also port to the new (months-old) xkbcommon API, as used by Weston 0.95.
This involves having xkbcommon manage the state for us, where
appropriate. Fans of multi-layout keyboards (or just caps lock) will no
doubt appreciate these changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Looks like we need to include this directly, but also need to include
cogl/cogl.h to get COGL_HAS_EGL_SUPPORT, since cogl-egl.h doesn't
include cogl-defines.h first.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If a button press happen on stage and the pointer is moved outside
the stage while holding the mouse button, the motion and release
events are still delivered to actors. Do the same X11 soft grab
emulation for touch events.
https://bugzilla.gnome.org/show_bug.cgi?id=685589
On various systems, trying to release a mutex that hasn't been acquired
will result in a run-time error.
In order to avoid this, we trylock() the Big Clutter Lock™ and
immediately unlock() it, regardless of the result; if the lock was
already acquired, trylock() will immediately fail, and we can release
it; if the lock was not acquired, trylock() will succeed, and we can
release the lock immediately.
This is necessary to maintain binary compatibility and invariants for
Clutter applications doing:
clutter_init()
clutter_threads_enter()
...
clutter_main()
...
clutter_threads_leave()
instead of the correct:
clutter_init()
clutter_threads_enter()
...
clutter_threads_leave()
clutter_main()
clutter_threads_enter()
...
clutter_threads_leave()
With Clutter ≥ 1.12, the idiomatic form is:
clutter_init()
...
clutter_main()
given that the public Big Clutter Lock™ acquire/release API has been
deprecated, and nobody should take the lock outside of Clutter itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679439
When the last touch has been released the stage on the
corresponding master device (eg. the virtual core pointer) is set
to NULL and no mouse events can be delivered until an ENTER event
has occurred and the stage pointer restored.
This is due to the fact that the master devices can send both
touch events and mouse events, forwarding events coming from the
attached slave devices.
To restore delivery of mouse events we need to ensure that the
stage is set on each ButtonPress, ButtonRelease and Motion event
coming from master devices.
https://bugzilla.gnome.org/show_bug.cgi?id=684509
When using the new ActorAlign flags we must get the real alignment for
the horizontal axis, as clutter_actor_allocate() will compute the
effective alignment by itself; if we use the effective alignment then
ClutterActor.allocate() will swap it, and undo our work.
When using the old BinAlignment flags we should reverse the alignment
depending on whether the text direction of the child is RTL or LTR.
See bug: https://bugzilla.gnome.org/show_bug.cgi?id=684214
It should be possible to destroy the actor currently being dragged from
within the ::drag-end signal. In order to do this, we need to keep a
reference on the action for the duration of the emit_drag_end() function
as well as resetting the action's state inside the dispose()
implementation, to avoid trying to access cleared data.
https://bugzilla.gnome.org/show_bug.cgi?id=681814
Modified Return key presses don't trigger ::activate so we would end
up adding an unprintable character to a single paragraph mode pango
layout which renders it as a box.
https://bugzilla.gnome.org/show_bug.cgi?id=623344
The code for calculating the content box when the aspect ratio is
greater than 1 was broken. The same code that did the calculation for
aspect ratio less than 1 should be used in all cases.
Fixes: https://bugzilla.gnome.org/682161
When we miss button release events (eg. when they happen outside
of our window) we must ensure that the corresponding point is
removed from the array of tracked points, otherwise GestureAction
will get very confused and will cancel all subsequent gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=683471
When starting a new gesture before the momentum of the previous one
has finished the ::pan-stopped was counter-intuitively emitted
after the new ::gesture-begin.
Make use of gesture_prepare() to reset the state of the action
right before emitting ::gesture-begin.
https://bugzilla.gnome.org/show_bug.cgi?id=683431
We often mean that when key_focus == NULL, it's assumed to be on the
stage, and clutter_stage_get_key_focus() reflects this. We also do a
lot of check around the lines of key_focus == NULL instead of also
checking for the stage, so make sure to normalize it so that explicitly
grabbing the stage's key focus will not change our behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=683301
The ClutterEventSequence structure is a fully opaque type; on X11, it is
just an unsigned integer that gets converted into a pointer, but in the
future it may become a fully fledged data structure.
Obviously, we cannot tell people to just dereference the pointer into an
integer in order to use it, and still retain the ability to change the
type; for this reason, we need a proper accessor function to convert the
EventSequence into a touch detail, to be used with the XInput API.
The ordering of the evdev button numbers is the opposite of the
order in Clutter (the middle button is 3 instead of 2) so we need to
manually map the button numbers when creating a ClutterButtonEvent.
https://bugzilla.gnome.org/show_bug.cgi?id=680255
803b3bafb6 introduced a new issue for
multi touch events.
In the case where 2 touch events for 2 different touch points are
processed in the same iteration, a call to
_clutter_stage_remove_device() when processing the first event will
remove the stage setting of the InputDevice. That means Clutter will
skip the second event, because it can't find a stage to which relate
the event, so no related actor and so no emission.
To fix this we move the _clutter_stage_(add/remove)_device() calls
into the input device. This way the input device can find out exactly
when to call these functions (i.e. when no touch point were previously
active or when no touch point remain active).
https://bugzilla.gnome.org/show_bug.cgi?id=682362
Interpolating between two transformations expressed using a 3D matrix
can be achieved by decomposing the matrices into their transformations
and do a simple numeric interpolation between the initial and final
states, like we do for other data types.
Luckily for us, the CSS Transforms specification from the W3C provides
the decomposition algorithm, using the "unmatrix" code taken from the
book "Graphics Gems II, edited by Jim Arvo".
Once the matrices have been decomposed, we can simply interpolate the
transformations, and re-apply them onto the result matrix, using the
facilities that Clutter provides for interpolating between two known
GTypes.
Since Cogl version 1.11.2, Cogl no longer includes the EGL headers
from cogl.h if COGL_ENABLE_EXPERIMENTAL_2_0_API is defined. Instead
the application needs to include cogl-egl.h so that we can avoid
polluting the global namespace with X defines. Clutter defines the 2.0
define in its configure.ac and it is relying on Cogl to include the
right EGL header in clutter-egl-headers.h so we need to change which
header it includes.
When changing an implicit transition mid flight we may end up with an
easing state with a duration of zero milliseconds; this leads to the
implicit transition machinery setting the final state directly onto the
actor. If there is a running transition, though, we need to remove it
from the transitions table, otherwise it will keep running.
This regression happened when the update_transition() internal function
was merged into the create_transition() one.
Tested-by: Lionel Landwerlin <llandwerlin@gmail.com>
PanAction is a GestureAction-subclass that implements the panning
concept for scrollable actors, with the ability to emit interpolated
signals to emulate the kinetic inertia of the panning. PanAction provides:
• pan signal, notifying users of the panning gesture status;
• pan-stopped signal, emitted at the end of the interpolated phase
of the panning gesture, if enabled;
• pan-axis property, to allow constraining the dragging to a specific
axis;
• interpolated property, to enable or disable the inertial behaviour;
• deceleration property, to customize the rate at which the momentum
of the panning will be slowed down;
• acceleration-factor property, applied to the inertial momentum when
starting the interpolated sequence.
An interactive test is also provided.
https://bugzilla.gnome.org/show_bug.cgi?id=681648
Add some accessors to simplify common tasks for GestureAction users:
• clutter_gesture_action_get_motion_delta() to get the delta
on the X and Y axis in stage coordinates since the last motion
event, and the scalar distance travelled;
• clutter_gesture_action_get_velocity() to get an estimate of the
speed of the last motion event along the X and Y axis and as a
scalar value in pixels per millisecond.
https://bugzilla.gnome.org/show_bug.cgi?id=681648
When appending (with a negative row/column parameter), the row/column
count should be incremented by 1, not 2. This also fixes layout errors
when using column/row spacing: The amount of extra space required was
calculated incorrectly due to the wrong column count.
https://bugzilla.gnome.org/show_bug.cgi?id=679990
When setting a drag handle, transform the original press
coordinates using the drag handle as reference instead of the
associated actor.
This causes the initial misplacement of drag handle in
example/drag-action when holding down the Shift key: the handle
gets placed at the main actor origin on the first drag event,
instead of following the mouse pointer.
All subsequent motion events already use the right actor when
transforming the coordinates, thus they are not affected.
https://bugzilla.gnome.org/show_bug.cgi?id=681746
If the DragAction has a drag handle that gets destroyed inside the
::drag-end signal handler, the destruction sequence will trigger a
callback we have in place to check if the handle is being destroyed
mid-drag, e.g. from a ::drag-motion event.
The callback on the drag handle destruction will check if we are still
in the middle of a drag and emit the ::drag-end signal to allow cleaning
up; the callback erroneously uses the drag handle as the argument for
the emit_drag_end() function — instead of the actor to which the drag
action has been attached. Also, by the time we emit the ::drag-end, we
are not dragging the actor any more, so we shouldn't be emitted the
::drag-end signal twice.
The fix is, thus, made of two parts:
- reset the in_drag boolean before emitting the ::drag-end signal
so that destroying the drag handle will not result in a double
signal emission;
- use the correct actor when calling emit_drag_end().
https://bugzilla.gnome.org/show_bug.cgi?id=681814
If the actor has a fixed position set, but it's not using the BinLayout
alignment enumeration to set its alignment, then we force the alignment
factor to 0.0; this is consistent with what happens with an explicit
alignment of CLUTTER_BIN_ALIGNMENT_FIXED.
https://bugzilla.gnome.org/show_bug.cgi?id=682265
Event handling should only apply to editable ClutterText actors, but we
also have the :selectable property to care about.
The button/touch press should position the cursor inside an editable
ClutterText; the :selectable property should be used to allow selecting
the text, either through pointer or touch dragging, via the keyboard, or
by multiple pointer clicks. If neither of these two conditions are met,
the ClutterText should just propagate the event handling further.
Allow setting a ClutterRect on the drag action and force the
dragged actor's position to be always within that rectangle (relative
to the actor's parent).
https://bugzilla.gnome.org/show_bug.cgi?id=681168
The boolean_handled accumulator will stop the signal emission if TRUE is
returned by a signal handler; the boolean_continue accumulator will stop
the signal emission if FALSE is returned. The first one is used for
event-related signals, while the latter is used for action-related
signals.
Only the signal connection. When using G_ENABLE_DIAGNOSTIC there will be
a warning for every signal connection.
We should try and discourage people from ever using the paint signal
ever again, until we can safely remove it in Clutter 2.0.
We cannot fully deprecate Geometry, because ClutterActor and ClutterText
are actually using the type in signals and properties; but we can
deprecate the API that uses this type, so that 2.0 will be able to avoid
it entirely.
The :clip property still uses ClutterGeometry, which is a very bad
rectangle type. Since we cannot change the type of the property
compatibly, we should introduce a new property using ClutterRect
instead. This also matches the ClutterActor.set_clip() API, which uses a
decomposed rectangle with floating point values, like we do with
set_position() and set_size().
Instead of only relying on the (now) deprecated BinAlignment.FIXED
enumeration value, we just ask the actor if a fixed position has been
explicitly set, under the assumption that if a developer decided to call
set_x(), set_y(), or set_position() on an actor inside a BinLayout then
she wanted the fixed position to be honoured.
This removes the last (proper) use of the BinAlignment enumeration.
The Geometry type is an *awful* representation of a integer rectangle,
as it uses unsigned integers for its size, leading to overflow issues
when unioning and intersecting. We have better rectangle types in
Cairo and Clutter, these days.
When dragging/scrolling using touch events, we want the same behaviour
than for motion events. We need to honor the user's calls to
clutter_stage_set_motion_events_enabled() to deactive event
bubbling/captured sequences on the actor located under the pointer and
just transmit events to the stage/grab actor.
https://bugzilla.gnome.org/show_bug.cgi?id=680751
We need to make sure that ClutterActor::transition-stopped is emitted
after the transition was removed from the actor's list of transitions.
We cannot just remove the TransitionClosure from the hash table that
holds the transitions associated to an actor, and let the
TransitionClosure free function stop the timeline, thus emitting the
::transition-stopped signal - otherwise, stopping the timeline will end
up trying to remove the transition from the hash table, and we'll get
either a warning or a segfault.
Since we know we're removing the timeline anyway, we can emit the signal
ourselves in case the timeline is playing, in both the implicit and
explicit cases.
The :transform property controls the modelview matrix of an actor; it
can be used to set a custom modelview matrix on the actor, as opposed
to the decomposed transformations (rotation, scaling, translation)
provided by the ClutterActor class.
The transitions we create implicitly should be removed from the set of
transitions associated to an actor; the transitions explicitly
associated to an actor, though, have to survive the emission of their
'stopped' signal.
We can remove the update_transition() private method, and move its
functionality inside the create_transition() private method, thereby
removing lots of duplicated code, as well as redundant checks on the
existence of a transition. This will allow handling transition updates
atomically in the future.
Another progress function from the CSS3 Transitions specification, using
a parametrices cubic bezier curve between (0, 0) and (1, 1) with two
control points.
(sadly, no ASCII art can approximate a cubic bezier, so no graph)
The cubic-bezier() progress function comes with a bunch of preset easing
modes: ease, ease-in, ease-out, and ease-in-out, that we can map to
enumeration values.
The CSS3 Transitions specification from the W3C defines the possibility
of using a parametrized step() timing function, with the following
prototype:
steps(n_steps, [ start | end ])
where @n_steps represents the number of steps used to divide an interval
between 0 and 1; the 'start' and 'end' tokens describe whether the value
change should happen at the start of the transition, or at the end.
For instance, the "steps(3, start)" timing function has the following
profile:
1 | x
| |
| x---|
| ' |
| x---' |
| ' |
0 |---' |
Whereas the "steps(3, end)" timing function has the following profile:
1 | x---|
| ' |
| x---' |
| ' |
x---' |
| |
0 | |
Since ClutterTimeline uses an enumeration for controlling the progress
mode, we need additional API to define the parameters of the steps()
progress; for this reason, we need a CLUTTER_STEPS enumeration value,
and a method for setting the number of steps and the value transition
policy.
The CSS3 Transitions spec helpfully also defines a step-start and a
step-end shorthands, which expand to step(1, start) and step(1, end)
respectively; we can provide a CLUTTER_STEP_START and CLUTTER_STEP_END
enumeration values for those.
This patch brings 'enter-event' and 'leave-event' generation for touch
based devices. This leads to adding a new API to retrieve coordinates
of a touch point.
https://bugzilla.gnome.org/show_bug.cgi?id=679797
We use floorf() for the allocation origin, and ceilf() for the
allocation size. Swapping the two introduces rounding errors if
the original allocation is not clamped to the nearest pixel.
This reverts commit 7f6b17bc50.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 793bde9143.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 320fb156b4.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 58a1854b57.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 03ec016faa.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
ClutterTexture is full of side effects that have been picked up over the
years; they make improving ClutterTexture harder than necessary, as well
as making subclassing impossible without introducing weird behaviours in
the child classes as well.
Since Clutter 1.10 we have the ClutterImage content type, which is
side-effects free, given that it just paints texture data using the
state of the actor.
Sadly, we still have subclasses of ClutterTexture, both deprecated and
not, so we cannot deprecate ClutterTexture right out; the type and
structures will still be available, like we do for ClutterGroup, but the
whole API should be moved to the deprecated section, waiting for the
time in which we can get rid of it all.
We need an alternative to the translation performed by the anchor point,
one that possibly applies to all three axes and is relative to the
pivot-point.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
For some transformations we need to be able to set the Z component of
the pivot point.
Unlike :pivot-point, the Z coordinate is not normalized because actors
are 2D surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
Given that the rotation transformations are now affected by the pivot
point, the Actor class should provide an accessors pair only for the
angle of rotation on a given axis.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The pivot point is a point in normalized coordinates space around which
all transformations revolve.
It supercedes the anchor point and the per-transformation center points
as well as the gravity settings, and tries to sort out the mess that
is the modelview matrix set up in ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The ClutterActor:depth property has always been a bit of a misnomer:
actors are 2D flat surfaces, so they cannot have "depth"; the property
defines the position on the Z axis.
Another side effect of the :depth property is that it decides the
default paint and allocation order on insertion, and that setting it
will call the ClutterContainer.sort_depth_order() method. This has
proven to be a fairly bad design decision that we strung along from the
0.x days, as it gives a false impression of being able to change the
paint and allocation order simply by changing the position on the Z
axis — something that, in reality, requires depth testing to be enabled
during the paint sequence of an actor's parent.
For 2.0 we need a clean break from the side effects, and a better
defined interface.
ClutterActor:z-position is essentially what ClutterActor:depth is, but
doesn't call into ClutterContainer, and has a more apt name.
https://bugzilla.gnome.org/show_bug.cgi?id=679465
The :position property on ClutterText clashes with the same property on
ClutterActor; it's also badly named, given that it represents the
cursor's position inside the text; finally, it does not match its
accessors, violating the API style conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=679457
Overriding the default behaviour of ClutterDragAction::drag-motion is
currently a pain; you either need to subclass the ClutterDragAction and
override the class closure for the signal, or you need to connect to the
signal and call g_signal_stop_emission_by_name() - neither option being
particularly nice or clean. The established pattern for these cases
would be to have a boolean return value on the ::drag-motion signal, but
we cannot do that without breaking ABI.
To solve the issue in a backward compatible way, we should introduce a
new signal, ::drag-progress, with a boolean return value. If the signal
emission chain returns TRUE, the ::drag-motion signal will be emitted,
and the default behaviour will be honoured; if the signal emission chain
returns FALSE, instead, the ::drag-motion signal will not be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=679451
Acquiring the Clutter lock to mark critical sections is not portable,
and not recommended to implement threaded applications with Clutter.
The recommended pattern is to use worker threads, and schedule UI
updates inside idle or timeout handlers within the main loop. We should
enforce this pattern by deprecating the threads_enter()/leave()
functions. For compatibility concerns, we need internal API to acquire
the main lock during frame processing dispatch.
https://bugzilla.gnome.org/show_bug.cgi?id=679450
It can be useful to check whether a ClutterActorIter is currently valid,
i.e. if the iterator has been initialized *and* if the actor to which it
refers to hasn't been updated.
We can also use the is_valid() method in the conformance test suite to
check that initialization has been successful, and that changing the
children list through the ClutterActorIter API leaves the iterator in a
valid state.
The dispose sequence will keep the object alive, and we need to release
the last reference held by the StageManager before releasing control to
GObject.
The build should not add deprecated/ into the default INCLUDE paths, so
that deprecated headers are clearly separated; this will make it easier
to get rid of them when we branch out for 2.0.
