The port to use ClutterPaintNodes basically mirrors what
it currently does, with the major benefit of not depending
on cogl_get_draw_framebuffer() anymore.
There are various factors that influence the number of
subnodes:
* The background color adds a color subnode;
* The selection adds a clip subnode, and a color subnode,
or a color and a text subnode;
The simplest case is when the text does not overflow and
has no background color nor selection. In that case, the
render tree is simply:
[ Dummy ]
↓
[ Text ]
In contrast, the most complex case is when drawing the text
with selection, in which case the render tree looks like:
[ Dummy ]
↓
[ Clip ]
↓
[ Text ] → [ Clip ]
↓
[ Color ] → [ Text ]
Since the selection may have another text color, the selected
text must be rendered again, but clipped to only cover the
selection rectangle. This is suboptimal, but it's what the
current code already does anyway.
When painting a ClutterText, there are two different aspects that
should be taken into account:
1. The allocated size of the actor; and
2. The reported size of the PangoLayout, which may be smaller or
bigger than (1)
When (2) is bigger than (1), ClutterText has to clip the text to
only draw at the visible contents over the actor surface. In
addition to that, ClutterText also tracks the cursor position,
which makes clipping a bit more complicated.
The current ClutterTextNode.draw() implementation assumes that
the (1) also represents (2), which is not true. This makes
clipping not work.
Fix that by assuming that the position to draw the PangoLayout
is passed as the second rectangle, and the actor size is the
first one.
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
