Drop some code, in favor of a numeric keypad that is driven through
the same JSON-based maps. This is also a first use of the "height"
key property in the JSON files, for the Enter key.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Do not hardcode the us-terminal OSK keymap, and append '-extended'
to the current group name, accounting with the existing 'us' fallback.
This allows for concerned individuals to propose language-specific
terminal layouts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This will allow OSK descriptions to declare "tall" keys. May be
used in combination with the "start" property added in previous
commits, in case a gap needs to be explicitly left.
No OSK description uses this yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This optional property defines the offset the a key should have
relative to the previous key (on its left) or the start of the
column if it is the first key. If this property is not
present, the key will be placed with no relative offset.
This for example allows keymaps to explicitly define the padding
of the rows that are not "full" relative to other rows, without
guesswork in the code. It is used for this purpose in the
keymaps/levels/rows that needed it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Previously backspace would only ever remove a single character left of
the cursor, regardless of selection.
This requires the application to correctly set the anchor position in
text_input::set_surrounding_text(), which currently only gtk4 seems to
do. When there is no selection or on other applications that always set
cursor = anchor, like gtk3 does, the behavior is not changed and still
only deletes one character.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
Since mutter@33088d59 the cursor we receive from mutter already is a
character index while the code here still treated it like a byte offset.
Further the code to detect the previous word position was treating the
cursor parameter already like a character index, while passing the
cursor that was prior to that commit a byte offset.
The function also had some unreachable and redundant code paths. The
pos < 0 case can never be reached due to the max(). Also the regex
already ensures that all whitespace is considered, so the code to remove
spaces not actually do anything except when deleting the first word in
the text, in which it would cause the first character to not get
deleted.
Also it was not handling characters with more than 2 bytes correctly. In
the presence of these JS string functions, such as search(), can not be
considered to operate on character indices anymore but rather the number
of UTF-16 byte pairs. Issues with this can be avoided by using
iterators, which unlike anything else iterate on characters, not byte
pairs and by not using the results returned by JS string functions for
anything but JS strings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
Given that this may lead to the shell to hang on gdm startup, and that
we expect the service to be up and running quickly, we can safely set a
5 seconds timeout instead of using the longer GLib proxy defaults.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
Since fingerprint service can now be started also if a conversation has
already began, we can also initialize the proxy asynchronously, without
the risk that the service won't be started early enough.
As per this, remove the usage of FprintDeviceProxy wrapper completely
since it's just not giving us anything here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
On ShellUserVerifier construction we used to start fprintd in a sync
fashion all the times, however in case the daemon had startup failures
or was hanging for whatever reason (like due to devices probing, given
that fprintd synchronously wait for them all to be initialized) we used
to just fail, leaving gdm or the lockscreen in a not usable state.
While this could be prevented with a try/catch statement, there's no
much point to wait for fprintd if that's not the default authentication
service, and so:
- If we use gdm-fingerprint as default auth method, use a sync call to
initialize it and in case of failures, just continue with fallback
authentication mechanism (password)
- Otherwise, asynchronously initialize fprintd and continue with the
ShellUserVerifier without fingerprint support until we got a reply.
In case the service fails to deliver us a result, we don't give up
but we will try doing that at each authentication via
_checkForFingerprintReader().
In case all works properly, as per the previous commit, once the
initialization is done, we'll start the fingerprint PAM gdm service.
Fixes#5168
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
If fingerprint service is not replying fast enough to our async request,
authentication is started but the fingerprint service is never started.
So, in case the fingerprint type information is received after that the
authentication has been started, let's start the service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
There's no point to initialize the fprint proxy and the smartcard
manager if they are disabled in authentication settings, so just avoid
initializing them, but at the same time this implies tracking of user
changes and so:
- If a new service has been enabled, we initialize it
- If a service has been disabled we destroy it and reset the
authentication if such service was currently active
In both cases we do update the default service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
If we have a late activation of a service backend we may need to check
whether it has been already started, and in case it has not, we can try
loading it.
So rely on gdm to see what service has been started, instead of handling
it manually on our side only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
There are multiple different places where we activate an app action,
but none set the correct activation token. Therefore this adds an async
method to to call `ActivateAction` on `org.freedesktop.Appliaction`
with the correct activation token/startup id as platform data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
We auto-close FDO notifications when the sender leaves the bus,
given that the protocol was created without persistency in mind
and any action will become invalid.
However that broke when moving the public-facing implementation
into a separate service, as we now track the (always running)
service instead of the original sender.
Fix that by forwarding the sender to the internal implementation
via a private hint, just like we already do for the PID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
The hint is a private implementation detail between the public
and internal services, not something anybody else should set
(*cough* libnotify *cough*).
Prefix the name to hopefully make that clearer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
commit c8bb45b41c3a13ef161103f649aa18938e028a70 introduced a new
verification state, VERIFICATION_IN_PROGRESS, to detect when the user
has already interacted with the authentication prompt, so the
prompt can rate limit the number of times the user can cancel
authentication attempts with the escape key (without also rate limiting
the number of times they can hit escape to go back to the clock without
interacting with the prompt).
That means there are now two states that represent the user actively
undergoing verification: VERIFYING and VERIFICATION_IN_PROGRESS.
It's inappropriate to reset the smartcard service if the user is
actively conversing with it. We try to check for that by looking at the
original verification state, VERIFYING, but we unfortunately, neglect
to account for the new VERIFICATION_IN_PROGRESS state.
The result is that if a user types their smartcard pin at the clock,
and then inserts their smartcard, the pin will get cleared instead of
used, and they have to retype it again.
This commit fixes the oversight, and allows users to again pre-type
their smartcard pin at the clock before inserting their smartcard.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2765>
Both timestamp and options parameters have been unused since
the switch to Clutter.grab(), so remove them.
Stop using Params.parse(), so that code that still passes the
parameters doesn't throw an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
It was added in commit 48fb16b570 for the lock screen, but that
hasn't been based on ModalDialog for a long time.
It doesn't appear that anything else ever used the parameter,
so just remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
