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.
