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>
Its parent `lockDialogGroup` has exactly the same background-color
set in the same file. Giving them both the same wasted render time on
overdraw, and caused multi-layer blending artifacts (slight flickering
of the grey background) when the login dialog fades in/out.
While the flicker can also be fixed using `set_offscreen_redirect`,
there's no point adding that overhead when the extra layer doesn't need
to be painted. Removing it halves the average render time of the login
animation.
Closes: https://bugs.launchpad.net/bugs/2036388
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3207>
Since the launch context may also be used to activate an action on an
running application with an already existing window, which we don't
necessarily want to move to a different workspace, don't set a workspace
for the launch context. If no active window exists for an application
then it will be place on the currently active workspace anyways.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
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>
