Commit Graph

15766 Commits

Author SHA1 Message Date
Carlos Garnacho
cbde13fc65 overview: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
0141b66d23 grabHelper: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
f1437506ea dnd: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
A S Alam
b9207e0e19 Update Punjabi translation 2021-02-14 00:50:19 +00:00
Balázs Meskó
1e422faeb8 Update Hungarian translation 2021-02-13 23:32:09 +00:00
Sebastian Keller
2501bc5c8f st/scroll-view-fade: Fix vertical top fading
The fade for the vertical top edge was calculating the fade ratio for a
larger height (up to where the bottom fade starts) than it was
displaying.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1674>
2021-02-13 21:00:46 +00:00
Panawat Wong-kleaw
8a76508f71 osk-layouts: Add additional keys to Thai layout
Add Anghankhu (๚), Fongman (๏), Khomut (๛), and Yamakkan ( ๎) keys.

These keys do not exist in most, if not all, Thai physical keyboards,
but may be used by those who study ancient Thai texts. However,
they are an optional part of the TIS-820-2538 spec[0].

[0] https://www.nectec.or.th/it-standards/std820/std820.html

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>
2021-02-13 17:28:23 +00:00
Panawat Wong-kleaw
478b45084c osk-layouts: Add a shift level to Thai layout
It is currently missing entirely from the generated layout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>
2021-02-13 17:28:23 +00:00
Carlos Garnacho
28f73a175c windowManager: Do not set Wacom LED state through g-s-d
This piece of machinery is going away, in favor of the own kernel's
support.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1075>
2021-02-13 15:52:55 +01:00
Lucas Werkmeister
bbf1fc28ca lookingGlass: Let history trim input
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>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
df94055c58 runDialog: Let history trim input
Checking whether the item is empty is now the history’s job, per the
previous commit. The history also returns the trimmed input for us, so
we can avoid doing that work twice.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
d31f805817 history: Trim input and ignore if empty
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>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
30203f2694 history: Use strict equality checks
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +00:00
Jakub Steiner
5dafc26b6d HC: Set legible app icons for window thumbnails
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3692

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1657>
2021-02-13 08:34:43 +00:00
Marco Trevisan (Treviño)
829a096ba1 gdm: Restart only the service that failed at verification-failure
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
85ad1157df gdm: Pass source serviceName to verification failures
Depending on the service name we got the failure from we could react
differently, so let's pass the value to the verification failure
handler.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
80a7a8ddb9 gdm: Ensure we cancel all the previously running services on auth retry
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
ca912f55cc gdm: Include the failed service name when in reporting errors
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
36fba1a184 gdm: Do not fail the whole authentication if a background service failed
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
0ccb8e27d4 gdm: Disconnect user verifier signals on destruction and verification failed
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
c936ca3ea0 gdm: Don't try answering query if the user verifier has been deleted
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
c8bb45b41c gdm: Limit verification cancellations to be conform to allowed-failures
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
7e77881717 authPrompt: Handle Escape key to cancel ongoing verification
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
3e96952fde authPrompt: Don't begin a new authentication session on lockscreen cancel event
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>
2021-02-12 20:26:00 +00:00
Marco Trevisan (Treviño)
b916df1110 gdm: Cancel user verification on UserVerifier destruction
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>
2021-02-12 20:26:00 +00:00
Florian Müllner
2beca14b8d windowPreview: Tie icon scale to overview state
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>
2021-02-12 19:48:43 +00:00
Fran Dieguez
74575ee330 Update Galician translation 2021-02-12 19:10:40 +00:00
Аляксей
338862f3e6 Update Belarusian translation 2021-02-12 16:18:19 +00:00
Bruno Lopes da Silva
ee330eabbd Update Brazilian Portuguese translation 2021-02-12 15:12:52 +00:00
Kukuh Syafaat
f788962473 Update Indonesian translation 2021-02-12 12:01:04 +00:00
Daniel Șerbănescu
df9766a239 Update Romanian translation 2021-02-12 10:20:30 +00:00
Georges Basile Stavracas Neto
c0a4d90847 overviewControls: Limit Dash height to 15% of the overview's
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>
2021-02-11 22:31:50 +00:00
Georges Basile Stavracas Neto
1b51ae150d searchController: General cleanup
Fix style issues, such as indentation and == → ===. Simplify
getTermsForSearchString() by removing one variable.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
2021-02-11 21:14:36 +00:00
Georges Basile Stavracas Neto
c8f1dca3c7 Rename ViewSelector to SearchController
Rename ViewSelector to SearchController, since ViewSelector now effectively
only handles search. Rename the file correspondingly as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
2021-02-11 21:14:36 +00:00
Georges Basile Stavracas Neto
27627bd40a viewSelector: Cleanup pages
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>
2021-02-11 21:14:36 +00:00
Yuri Chornoivan
692b6d2577 Update Ukrainian translation 2021-02-11 20:40:03 +00:00
Anders Jonsson
960f87ede6 Update Swedish translation 2021-02-11 19:46:04 +00:00
Jonas Dreßler
3510b88bdc screenshot: Remove shooter from sender in finally block
We do this in both the try{} and the catch{} block, so we might as well
put it into a finally{} block.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
2021-02-11 18:51:40 +00:00
Jonas Dreßler
c1bfdd74d8 screenshot: Fix slow audiovisual feedback on when taking screenshot
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>
2021-02-11 18:51:40 +00:00
Jonas Dreßler
461c65c93b screenshot: Replace template strings with .format()
CI will complain when we add screenshot.js to the POTFILES in the next
commit because gettext doesn't like template strings, so make CI happy
and switch to .format() instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
2021-02-11 18:51:40 +00:00
Brion Vibber
f9652aab82 Fix for screenshots when pictures path is unavailable
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>
2021-02-11 18:51:40 +00:00
Georges Basile Stavracas Neto
86cefd906b workspace: Disable overlay for inactive workspaces too
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>
2021-02-11 17:21:48 +00:00
Georges Basile Stavracas Neto
2e817d3fa8 workspace: Always leave overview when in app grid state
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>
2021-02-11 17:21:48 +00:00
Florian Müllner
d6a1414a94 extensions-app: Use development profile for nightly build
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3612

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1661>
2021-02-11 17:47:27 +01:00
Florian Müllner
5069572f85 extensions-app: Stop prefixing .desktop file
Adding prefixes like (Nightly) is discouraged nowadays in favor of
the radioactive icon overlays.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3612

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1661>
2021-02-11 17:47:27 +01:00
Florian Müllner
6bea1e7a47 extensions-app: Include commit hash in nightly version
It's useful information for development snapshots, so include
it when building from a git checkout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3612

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1661>
2021-02-11 17:45:00 +01:00
Florian Müllner
60d640189b extensions-app: Support building a separate Devel app
Follow the pattern used by most GNOME applications and add a profile
build option that allows building a Devel app instead of the regular
release.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3612

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1661>
2021-02-11 17:45:00 +01:00
Florian Müllner
e8ca92a0ff extensions-app: Pick up app ID from package
This will allow us to build different applications from the
same sources (namely "Extensions" and "Extensions Nightly").

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3612

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1661>
2021-02-11 17:45:00 +01:00
Georges Basile Stavracas Neto
bf1fa3879f workspacesView: Interpolate against relative workspace boxes
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
9c6d8e2aad overviewControls: Cache workspaces boxes
Next commit will need to access the allocated workspaces boxes, so
cache them at allocation time.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00