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
