gjs throws exceptions on non UTF-8 strings which, in some cases, crash
gnome-shell. ICCCM string properties are defined to be Latin-1 encoded
so we can try to convert them to avoid it.
Note that _NET_WM_NAME is defined to be UTF-8 and we already validate
it in utf8_string_from_results() .
https://bugzilla.gnome.org/show_bug.cgi?id=752788
printf string precision counts bytes so we may end up creating invalid
UTF-8 strings here. Instead, use glib's unicode aware methods to clip
the title.
https://bugzilla.gnome.org/show_bug.cgi?id=765535
This makes us behave the same both on bind and when an output
changes. In particular, we were not sending scale and done events on
output changes. We were also unconditionally sending mode events on
output changes even though these should only be sent if there is an
actual mode change.
https://bugzilla.gnome.org/show_bug.cgi?id=766528
Stacking hidden X windows below the guard window is a necessity to
ensure input events aren't delivered to them. Wayland windows don't
need this because the decision to send them input events is done by us
looking at the clutter scene graph.
But, since we don't stack hidden wayland windows along with their X
siblings we lose their relative stack positions while hidden. As
there's no ill side effect to re-stacking hidden wayland windows below
the X guard window we can fix this by just doing it regardless of
window type.
https://bugzilla.gnome.org/show_bug.cgi?id=764844
If we try to send notify event (either from surface_state_changed()
or from meta_window_wayland_move_resize_internal()),
we will crash, because we don't have a sufrace anymore.
There's no reason why to resize the window that is being
unmanaged anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751847
meta_parse_accelerator() considers 0 length accelerator strings as
valid, meaning that the keybinding should be disabled. Unfortunately,
it doesn't initialize the MetaKeyCombo so if the caller doesn't
initialize it either, we end up using random values and possibly
grabbing random keys.
https://bugzilla.gnome.org/show_bug.cgi?id=766270
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
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.
This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.
Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
meta_wayland_tablet_manager_update()/handle_event() are called before
the MetaWaylandSeat counterparts. If the event comes from a device
managed by MetaWaylandTabletManager, the event will be exclusively handled
by it.
Each tool has its own MetaCursorRenderer instance, which is created/destroyed
upon proximity, and possibly updated through focus and set_cursor calls in
between.
This struct keeps the server side information for the wl_tablet_manager
global resource. It keeps the clients requesting this interface, and
does keep track of the plugged tablet devices, so
wl_tablet_manager.device_added is emitted on the expected clients.
Move into a standalone meta-wayland-surface-role-cursor.[ch], and
make generic enough to work for pointe and additional (eg. tablet)
cursors.
Most notably, the sprite is now kept completely internal to the
cursor role, and updates are routed through the given
MetaCursorRenderer (which may be the default one for the pointer,
or something else).
The way cursor updates after cursor surface destruction has also
been reworked, the pointer will just keep track of the last cursor
surface, so older surfaces being destroyed don't trigger pointer
rechecks/updates.
There's places where it would be convenient to add listeners to this,
so add the signal. The signal is only emitted once during destruction,
it is convenient for the places where we want notifications at a time
the object is still alive, as opposed to weak refs which notify after
the fact.
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.
