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
