Instead of adding it to the window previews container, add it to Workspace
itself. This requires expanding WorkspaceBackground, so add the relevant
x and y expand flags.
Since the background is beneath the window previews, create and add it before
the window preview container.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
Currently, Workspace is a single actor that contains both the background,
and all window previews, and is managed by WorkspaceLayout. In the future,
this concentrating aspect of it will bite us; we want the window previews
to be clipped to the allocation, but not the background, since it will
have shadows.
Make Workspace subclass St.Widget with a ClutterBinLayout as layout manager,
and move window previews to a child actor. To reduce the impact of this
extra actor, it's a ClutterActor instead of a StWidget, and the spacing is
still set on Workspace itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The WorkspaceBackground class has specific code to clip the background
to the workarea. However, it doesn't monitor for workarea changes, which
means it cannot react after being created.
Connect to 'workareas-changed', and update the workarea, the radius bounds,
and relayout when workareas change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The primary workspace is displayed in the overview, and clipping it
ends up clipping the shadows too. Since Overview's ControlsManager
itself clips to allocation, no windows in the primary monitor spill
to other monitors. However, not clipping non-primary monitors might
end up in situations where their windows spill into the primary one.
Make sure to only clip workspace views of non-primary monitors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1699>
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().
Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.
So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).
So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.
Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
The scale property tracks the relative size at which we display thumbnails
given the space we have available.
That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.
Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.
However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.
Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
We currently have two components that show or hide the minimap:
- the thumbnails hide themselves in case of a single static workspace
- overview controls show the minimap when no search is active
That obviously doesn't work correctly.
To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.
To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.
Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1695>
The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.
This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.
The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.
Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.
But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).
Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touch swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the touch events and look if it matches
the expected orientation before accepting the gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Make the touchpad gesture keep track of its state, and enter in a
rejected state if the swipe is happening in the wrong direction.
Effectively, this means touchpad gestures are locked on a single
direction, and horizontal+vertical swipeTrackers won't be handling
events at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touchpad swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the swipe events and look if it matches
the expected orientation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
Even if activePage has been removed as part of commit 27627bd40, we've
still a reference of it in key press handler.
Given that there's no anymore an active page to redirect input to,
remove these references, so that can be handled in the proper view to
implement key-navigation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1688>
When opening a large number of windows, the computed space and scale for
a layout can become negative due to the per-row/per-column spacing. This
is smaller than the initial values of lastSpace and lastSpace, leading
to a null return which then causes all sorts of other issues resulting
in the workspace becoming invisible.
This change ensures that the function always returns a layout, even if
it may look a bit broken and does not conform to the scale/space
requirements which are impossible to fulfill for the given number of
windows. It's better than displaying nothing, since it allows users to
move/close windows and restore this to a more usable state.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3730
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1685>
When we got an error, all the other HINT or INFO messages are not useful
anymore and delaying to show them is just a waste of time and may be
even wrong in scenarios with fast authentication devices.
An example are the fingerprint devices, where the user may touch the
sensor repeatedly while we may still show the "touch the sensor" hint
instead of notifying of possible errors.
So, in case we got an error override all the other errors coming from
the same service with lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
Once the verification has been stopped or has failed all the messages
that are not of error type are just not needed or wrong to show.
For example, in the fingerprint case we may still show the hint to swipe
or touch the device, while the fingerprint PAM service has already been
stopped.
So filter them by adding a new function that adds a null message to the
queue, overriding all the messages that have a lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
There are cases in which a service may want to override a message with
one coming with higher priority, for example an info or hint message
isn't useful anymore if we've already got an error message.
In the same way when a service has been stopped we don't care anymore
showing its info or hint messages, while it still may be relevant to show
errors.
An example is the fingerprint service that may emit errors quickly while
the hints messages should not be kept around when an error is already
queued or when the service has been stopped.
So, add function that allows to override queued messages based by their
type that follows this policy:
- Messages coming from different services are always preserved in
their original order.
- Messages (from the same service) with a priority equal or higher than
the last queued one are preserved.
- Messages matching completely the last queued are dropped in favor of
this one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
It can be convenient to get the currently showing message in order to
replace or remove it in case it's not needed anymore.
So simplify the message queue handling by only depending on a single
local variable (_messageQueue) and redefining hasPendingMessages
depending on its content.
Now messages are kept in queue till they are not fully processed and the
first message is always the one currently shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
When a fingerprint failure event happens we may also soon receive a
conversation-stopped event with an error message (such as in the case
we hit the MAXRETRIES value), but this is going to be ignored in case we
are too quick in consider the first failure a verification-failed event
because that implies disconnecting from all the events and then ignoring
such signals.
To prevent this, add a small timeout before failing the verification so
that if we get a further event we will process it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it, however this can lead to
troubles since commit 7a2e629b as when the service conversation was
stopped we had no way to figure out this case and we'd end up to
eventually fail the whole authentication.
However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.
So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error as we did before commit 7a2e629b, without bothering
failing the whole verification.
In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3734
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>
Currently when the foreground service conversation stops we increase the
verification failed count and try to start it again, while if a
background service has been stopped we just ignore it.
This is causing a various number of issues, for example in the case of
the fingerprint authentication service, it is normally configured to die
after a timeout, and we end up never restarting it (while the UI still
keeps showing to the user the message about swipe/touch the device).
So, in such case let's just consider it a "soft" verification failure
that doesn't increase the failures count but will cause us to reset the
UI and try to restart the authentication (and so the affected service).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Wiggle may make the error message to be visible for less time so provide
the auth prompt an API to increase the timeout to be used for showing a
message in some cases.
This could be reworked when we'll have a proper asyn wiggle function so
that we could just make the user verifier to "freeze", then await for
the wiggle transition to complete and eventually release the verifier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Currently whenever an authentication failure happens we wiggle the
entry, however this may not be related to the service which failed.
For example if the fingerprint authentication failed for whatever reason,
there's no point to wiggle the text input as it's something unrelated to it.
So, only apply the wiggle effect to the entry in case the failure is
coming from the querying service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
By giving to the AuthPrompt information regarding the source service
name (and so the ability to know whether it's a foreground service) can
give it the ability to behave differently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Fingerprint PAM module can have multiple failures during a runtime
and we rely on the pam module configuration for the maximum allowed
retries.
However, while that setting should be always followed, we should never
ignore the login-screen's allowed-failures setting that can provide
a lower value.
So, once we have a fingerprint failure let's count it to increase our
internal fail counter, and when we've reached the limit we can emit a
verification-failed signal to our clients.
As per this we need also to ignore any further 'info' messages that we
could receive from the fingerprint service, as it may be configured to
handle more retries than us and they might arrive before we have
cancelled the verification session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Decouple the verification failure count increase from
_verificationFailed as there are some cases in which we may want to
increase it without emitting a verification-failed signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
When the login/lock screen is shown the error messages for background
services are always ignored.
However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.
This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.
Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.
[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.
The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
This ports the runDialog changes of [1] to the underlying history
component, where they can benefit looking glass as well: the history is
now responsible for trimming the input and deciding that it shouldn’t be
stored if empty. (Note that _setPrevItem and _setNextItem already
skipped updating the history if the entry was empty.)
Since both users, runDialog and lookingGlass, also need the trimmed
input for other reasons – runDialog to avoid issues when interpreting
the command as a file path (if it can’t be executed as a command),
lookingGlass to decide whether a command should be run at all – have
addItem return the trimmed input. (runDialog and lookingGlass are not
yet changed to take advantage of this – that will be done in separate
commits.)
[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
When verification failed using a specific authentication service we're
currently restarting the whole user authentication system, which leads
to lots of unneeded operations (reinitializing a new user verifier proxy,
restarting all the gdm workers with the relative PAM modules and so on).
And this makes also debugging of login problems more complicated, given
we're cluttering the journal with repeated data.
However, at reauthentication failure GDM has already set up for us an
user verifier that we can use reuse to start only the service that had a
failure. So when possible, just start a new service instead of rebooting
the whole authorization process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.
Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).
So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
In case a background service such as the fingerprint authentication
fails to start we'd just mark the whole authentication process as
failed.
Currently this may happen by just putting a wrong password when an user
has some fingerprints enrolled, the fingerprint gdm authentication
worker may take some time to restart leading to a failure and this is
currently also making the password authentication to fail:
JS ERROR: Failed to start gdm-fingerprint for u: Gio.DBusError:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed:
Could not create authentication helper process
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
### Promise created here: ###
_startService@resource:///org/gnome/shell/gdm/util.js:470:42
_beginVerification@resource:///org/gnome/shell/gdm/util.js:495:18
_getUserVerifier@resource:///org/gnome/shell/gdm/util.js:405:14
async*_openReauthenticationChannel@resource:///org/gnome/shell/gdm/util.js:378:22
async*begin@resource:///org/gnome/shell/gdm/util.js:194:18
_retry@resource:///org/gnome/shell/gdm/util.js:561:14
_verificationFailed/signalId<@resource:///org/gnome/shell/gdm/util.js:584:30
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:268:14
_queueMessageTimeout@resource:///org/gnome/shell/gdm/util.js:273:18
_queueMessageTimeout/this._messageQueueTimeoutId<@resource:///org/gnome/shell/gdm/util.js:288:65
Given that background services are ignored even for queries or any kind
of message, we should not fail the authentication request unless the
default service fails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a verification session has failed we may want to wait for the user
to have completed all the waiting queries and to have read all the
incoming messages, however during such time an user verifier should
not be allowed to queue further messages to the UI, as we're about to
completely stop the identification or start a new one.
Unfortunately this is not true because we're still connected to the
identifier signals, and so we may still show messages.
This is particularly true when using the fingerprint PAM module as it
may restart the authentication while we're in the process of stopping
it.
So, keep track of all the signals we've connected to, and disconnect on
verification failed and during cancel/clear operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Answering a query may be delayed to the moment in which we've not any
more messages in the queue, however this case can also happen just after
we've cleared the UserVerifier and in such case we'd have nothing to
answer, but we currently throw an error:
JS ERROR: Exception in callback for signal: no-more-messages:
TypeError: this._userVerifier is null
answerQuery/signalId<@resource:///org/gnome/shell/gdm/util.js:249:17
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:266:14
_clearMessageQueue@resource:///org/gnome/shell/gdm/util.js:301:14
clear@resource:///org/gnome/shell/gdm/util.js:223:14
cancel@resource:///org/gnome/shell/gdm/util.js:205:18
reset@resource:///org/gnome/shell/gdm/authPrompt.js:482:32
cancel@resource:///org/gnome/shell/gdm/authPrompt.js:569:14
vfunc_key_press_event@resource:///org/gnome/shell/gdm/authPrompt.js:128
So handle this case more gracefully keeping track of the current
cancellable and checking whether it is still valid before trying to answer
a query or do a delayed action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
As per previous commit the user can cancel an ongoing authentication via
Escape key and that will always send the user back to the clock view in
lockscreen or user-selection view in login prompt.
However, we can be a little more permissive and don't switch view to be
able to restart the authentication without further action.
To avoid this to be abused though, we consider the user verification
cancellation via escape key to be a "soft-failure", so once the
configured "allowed-failures" gsettings value has been reached, we'd
just act as before, ignoring any further request (until we don't get
back to the user auth view).
In this way we still make brute-force attacks harder to do, while still
giving the well-behaving user some ability to fix mistakes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Escape key is supposed to cancel a verification, however if the user
already hit Enter to begin the authentication the Escape key won't work
until the verification completed.
This may be quite inconvenient when an user did a typo while writing and
wants to cancel the already started auth.
So, while authenticating (or in general while the entry is unsensitive)
give the key focus to the authpromt itself so that we can still get the
input events and cancel an user action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a cancel event in the user lockscreen happens we first emit a reset
signal and immediately a cancelled one.
This lead to start a new gdm worker for each enabled authentication
method and then immediately to stop it.
As per the previous commit, we don't have anymore dangling gdm workers
around, but still we should not even start a new one in such case.
So, when the user explicitly cancelled the authentication session, first
emit a cancelled event and only emit a reset event with a begin request
if we are outside the lockscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When we cancel an user authentication via Escape key or cancel button on
AuthPrompt we reset the view and we emit a 'cancelled' signal that leads
to destroying the auth prompt and the user verifier.
However, the verifier may still have an operation in progress and its
completion may take some time (as in the case of gdm-fingerprint), but
we just leave the gdm worker running until its pam module completes
(potentially never) clearing and disposing its handle.
So, instead of just clearing the verify, actually cancel and clear it.
In case the user verifier is set, clearing the relevant data will happen
anyway as part of the cancel() call.
Ideally this would have been handled by gdm itself, but unfortunately we
can't fix it there because the verifier itself is a class generated by
gdbus-codegen, so we can't handle this automatically on disposal nor we
can automatically monitor when the caller proxy is stopped on our side.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Scaling the icons all the way from/to 0 is a relatively big transition,
which is fairly distracting when playing simultaneously for multiple
previews after reaching the WINDOW_PICKER state.
Instead, tie the scale to the overview state itself, so that the animations
runs in parallel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1654>
Back when the Dash was vertical, the size of each item was calculated
solely based on the available height. After making the Dash horizontal,
this was swapped by the available width. However, when the height of the
Dash decreases, the current code results in never scaling them up ever
again.
Fix that by making ControlsManagerLayout explicitly pass the maximum Dash
sizes. Remove the 'notify::width' handler that served the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1638>
Remove the dummy applications page that was introduced as a temporary
step. Replace the 'page-changed' and 'page-empty' signals with a 'search-active'
boolean property.
Remove ViewSelector.ViewsPage since it's now unused, and all the page handling
mechanism. At last, since we don't use any ShellStack features anymore, simply
make it a St.Widget with a ClutterBinLayout as the layout manager.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
In addition to disabling the overlay when the state is not 1,
disable it also when not in the active workspace.
Make the Workspace class track the workspace's active state,
and resync the overlays when it changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The behavior of workspaces is different depending on whether
the overview is in window picker state, or app grid state.
When in window picker state, clicking on adjacent workspaces
should only activate them, without hiding the overview; and
clicking on the active workspace hides the overview. When in
app grid state, clicking on a workspace must always hide the
overview.
Pass the overview adjustment to Workspace, and leave overview
if the overview state is bigger than WINDOW_PICKER.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The overview transition consists of getting the initial and final
states of the overview adjustment, derivating various other internal
states from them (such as the fit mode, opacities, translations, etc),
and finally interpolating the allocation boxes.
When interpolating between the fit mode, WorkspacesView uses the current
allocation box to derivate the SINGLE and ALL fit mode boxes. However,
that creates a curved path during overview transitions. What we really
want to do here is calculate the fit mode box relative to the corresponding
overview state. For example:
+----------------+----------+------------------------+
| Overview State | Fit Mode | Workspaces geometry |
+----------------+----------+------------------------+
| HIDDEN | SINGLE | Cover entire screen |
| WINDOW PICKER | SINGLE | Between minimap & Dash |
| APP GRID | ALL | 15% screen height |
+----------------+----------+------------------------+
Using the table above as the reference, when the overview transitions
between WINDOW PICKER and APP GRID, we must interpolate between
(SINGLE fit mode @ between minimap & Dash) and (ALL fit mode @ 15% screen
height). That way, we always interpolate the final boxes, which corrects
the odd path that workspaces follow during this transition.
Make the WorkspacesView of the primary monitor use these cached boxes
when the overview is in the middle of a transition, and the fit modes of
the initial and final state differ, to calculate the workspaces positions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
It makes more sense in a spatial overview that the app grid
comes and goes to somewhere in the screen, instead of fading
in and out into the void.
Make the app grid rise from the bottom of the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
