At the moment the on-screen keyboard doesn't emit the key release event
until the user stops pushing the keyboard button with their pointer.
This means if the user uses the pointer to hold the button down, it can
generate repeat events for some keys.
But this creates a bit of an inconsistency in behavior between keys that
support multiple choices via long press and those that don't. The ones
that support long press, don't repeat, instead they show the available
choices.
Furthermore, key repeat doesn't work for any of the keys with the
wayland backend, since key repeat is a client side thing, and we just
don't have it implemented for this path.
Given key repeat is a dubious feature in an on-screen keyboard to begin
with, and it's only implemented for one backend, and it's not even
completely working on that backend, it's probably best to drop support.
This commit changes the on-screen keyboard to always emit a key
release immediately after each key press.
keyboard: Use === instead of == when comparing actions
This just updates a part of the code to follow current recommended
practice for equality testing, in preparation for it to be updated.
4d1ce0d...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
notificationDaemon: Fix sound-file support
When commit 25bfe99ed53b5b7 replaced the thin libcanberra wrapper
with the (then) new MetaSoundPlayer API, it missed that the latter
expects files as GFile instead of a file path.
a3dcdaa...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
screenshot: Unrestrict PickColor
Commit dd2cd6286cd3 restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
st/icon: Ensure icons are updated if theme node is invalid
Icons that are changed while an actor is not mapped may not have a theme
node associated with, and thus we'd end up not updating them at all.
In fact we return early in st_update_icon(), and this was not an issue
until commit 0b1dfbf6f3f, because we'd end up to update the icon anyways
once the style was changed (and so with a valid theme node), but since
such change we might not updating the icon if no theme detail changed.
To prevent this, add a flag to require an icon update when the theme
changed, if no successfully update happened earlier.
