The session mode determines whether the screen casting should work or
not, but until now only dealt with the built in screen cast, not the
ones using PipeWire. Add the newly added API for inhibiting remote
access when the session mode says screencasts are not allowed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
getEvents() filters all events for the given range and sorts the result.
That's more than we need when checking whether there are any events,
where we only care that there's at least one event in the range.
Address this by splitting out the event filtering into a generator
function, so hasEvents() can return after at most one iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We track messages so that we can account for just added and removed
events instead of having to rebuild the entire list, however it's
also possible that the time or summary of an existing event changed.
Account for that by updating existing messages in-place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We currently let the entry of the autoPrompt grab the key focus inside
setQuestion(), which is called from _onAskQuestion(), which is the
callback of the "ask-question" signal.
It seems that the "ask-question" signal isn't emitted again right after
the password-check failed, but a few seconds after that. Since we get
the "verification-failed" signal earlier than "ask-question" (right
after we know the check failed) and we also get a hint whether the entry
should be usable again with the canRetry argument, we can also grab key
focus to in the same step.
So do that by grabbing key focus when making the entry sensitive.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2655
The additional function UnlockDialog.addCharacter() is only used at one
place, so we can simply remove it and call AuthPrompt.addCharacter()
directly. The AuthPrompt is shown right before that anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1209
Normally, we inhibit suspend while locking the screen. But in the
session mode used for gnome-initial-setup locking is not supported, so
in that case this inhibit call is pointless and should be avoided.
Without this patch you get the following error when you suspend and
resume during initial setup:
JS ERROR: Error getting systemd inhibitor: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation
inhibition has been requested for is already running
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
On Fedora 32 if you close the laptop lid during gnome-initial-setup,
gnome-shell hits this error:
JS ERROR: Exception in callback for signal: prepare-for-sleep: TypeError: this._dialog is undefined
_resetLockScreen@resource:///org/gnome/shell/ui/screenShield.js:434:9
activate@resource:///org/gnome/shell/ui/screenShield.js:571:14
lock@resource:///org/gnome/shell/ui/screenShield.js:617:14
_prepareForSleep@resource:///org/gnome/shell/ui/screenShield.js:219:22
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_prepareForSleep@resource:///org/gnome/shell/misc/loginManager.js:198:14
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_convertToNativeSignal@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:169:19
This is because _ensureUnlockDialog() hit its first early return. So
return early from activate() in that case, so this._dialog doesn't get
used while it's null.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
StButton returns CLUTTER_EVENT_STOP in various circumstances, but
AppIcon throws that away and returns CLUTTER_EVENT_PROPAGATE even
when it should stop.
Return the parent class' result instead of CLUTTER_EVENT_PROPAGATE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1211
These properties are never written; in the base class they are always
their default values, and in the subclasses the getters are overridden.
This will be necessary because GJS is adding checks to make sure that
readable properties always have a getter, writable properties always
have a setter, and that the variations of camelCase/snake_case are
handled correctly. It's supposedly backwards compatible, but that
assumes that code is not doing things like forgetting a setter on a
writable property. (If the missing setter had ever been called, it might
have led to a crash, which is why we've made this change.)
This is the minimally invasive patch which should work with both older
and newer versions of GJS. If you decide to require GJS 1.65.2, then
you'll also be able to remove the getters from NotificationPolicy as
well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1205
We want the spinner to be centered with regard to the entry, but
constraining the height breaks that:
1. clutter_actor_allocate() is called with the available size
2. clutter_actor_update_constraints() then adjusts that according
to the constraints
3. clutter_actor_adjust_allocation() applies the margin/expand/align
properties.
The issue there is that 2. reduces the allocation to the desired size,
so there is no more extra space to distribute in 3.
We can fix this by either constraining everything (and rely on the
cancel button's alignment) or limit the constraint to the width. The
latter seems more appropriate, given that the constraint is only used
to center the entry horizontally.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2628
When handing the resetDialog request we're leaving a source ID alive,
leading this error:
(gnome-shell:22464): GLib-CRITICAL **: 17:46:11.065: Source ID 12934 was not
found when attempting to remove it:
== Stack trace for context 0x55c9246916c0 ==
#0 55c9249151b8 i js/ui/components/polkitAgent.js:391 (11f71fd544c0 @ 100)
#1 7ffc55140aa0 b self-hosted:1009 (3062ba49af88 @ 423)
#2 55c924915120 i js/ui/modalDialog.js:167 (1c9e50ae9880 @ 62)
#3 55c924915098 i js/ui/modalDialog.js:186 (1c9e50ae9970 @ 12)
#4 55c924915008 i js/ui/environment.js:75 (1c9e50a8d5b0 @ 98)
#5 55c924914f78 i js/ui/environment.js:149 (1c9e50a8d9e8 @ 14)
So, reset the source handle to avoid trying to remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1203
Clutter.Animation doesn't contain any animation modes, they live in
Clutter.AnimationMode. The places we did `Clutter.Animation.WHATEVER`
just evaluated to `undefined`. Thus, use the correct namespace for the
animation mode enums.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1199
Translations are provided by .directory files, so trying to look
up a category name without the suffix will always fail.
Commit 343b3351f1 tried to fix this previously by changing the
saved keys, but that broke existing translatable folders.
Appending the .directory suffix for the lookup instead fixes the
issue without regressing non-custom folders.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2623
Right now, the actor hierarchy is such that the scroll view
does not contain the actual grid. It looks as follows:
StScrollView
↓
StBoxLayout
↓
ShellStack
↓ ↓
PaginatedIconGrid StWidget
This hierarchy can be slightly reorganized by changing it to be as
follows:
ShellStack
↓ ↓
StScrollView StWidget
↓
StBoxLayout
↓
PaginatedIconGrid
This will simplify future work where the PaginatedIconGrid will be
an implementation of StScrollable, in which case we'll be able to
simply remove the StBoxLayout from there.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1191
If a search provider is installed by an app which is blacklisted for the
current user by their parental controls, don’t show it or results for
it.
Currently, this only filters ‘remote’ (not built-in to the shell) search
providers. This seems fine for now; in future it could be expanded to
also filter built-in search providers, if any of them end up needing to
be filtered.
No corresponding changes need to be made `remoteSearch.js`, because the
results of `loadRemoteSearchProviders()` are filtered in `search.js`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
Filter the apps shown on the desktop and in search results according to
whether they are blacklisted by the user’s parental controls.
This supports dynamically updating the filter during the user’s session.
This adds an optional dependency on libmalcontent. If that’s unavailable, no
parental controls filtering will occur.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
While we now deal more gracefully with adapter removals, we can
still mess up the hadSetupDevices tracking:
As adapters become available before any devices, we'll always
reset the setting to false when Bluetooth is turned on. And if
no set up device happens to be in range, it will still be false
when Bluetooth is turned off again.
To address that, only update the setting if we have an adapter
(like we do now) and we had one before (so it wasn't the adapter
itself that changed).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Our intended behavior when bluetooth is turned off is to keep
the menu visible if devices had been set up previously.
However since gnome-bluetooth@c437c729, devices are removed
first before removing the default adapter, so we now end up
always setting the property to false before checking for it.
Fix this by deferring all model changes to an idle, so that
we can process them as a unit. Do the same for proxy property
changes, as those may trigger a row-removal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Since commit 26c2cb9f65, nDevices is always the actual number of
paired/trusted devices. So when bluetooth is turned off, it is
now 0 rather than forced to 1 if devices were set up previously.
Fix this by checking the property that tracks set up devices instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Pretty much the same case of the previous commit: we want this size
to be scale-dependant, and using the width and height properties of
ClutterActor doesn't automatically update.
Use CSS to set the width and height.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
The return value of st_theme_node_lookup_length() is scaled according
to the scale factor. IconGrid.ICON_SIZE is not. However, when BaseIcon
tries to fetch the CSS value for "icon-size" (which returns a scaled
value), it uses it as-is, mixing the two coordinate systems.
Use a single coordinate system (unscaled sizes) in IconGrid.BaseIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1175
Usually the screen is woken up before the shield is deactivated, but
it is also possible to unlock the session programmatically via the
org.gnome.ScreenSaver D-Bus API.
The intention is very likely not to unlock a turned off screen in
that case. Nor does it seem like a good idea to change the lock
state without any indication.
Waking up the screen is more likely to meet expectations and is
more reasonable too, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1158
Extension that want to expose their own preferences (for example as menu
items) do that by passing their UUID to gnome-shell-extension-prefs.
But since 3.36.1 the app is optional and no longer accepts arguments on
the command line. To adjust, extensions now need to make a D-Bus call
the extensions portal, just like the app and gnome-shell.
We will add a convenience method for that purpose, so it makes
sense to share the existing code. As it's extension-related, the
extension manager looks like the right place ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
A promisified method expects the callback parameter to be either
a function (in which case the original method is called normally)
or omitted altogether (in which case a Promise is returned).
The call to open application details in Software does neither and
passes null instead, which will result in a warning (because no
function argument means a promise will be used, but not omitting
the parameter means we end up with too many arguments).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
In case where only one device is connected, we want to display its name
in the menu. For that we will need more than the number of known/connected
devices, so change the function to return an array of device infos instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2340
During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).
In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.
So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.
At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1156
In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.
Fix this by removing any lingering signal or later handlers when
unmapping.
Fixes: 5c33fe4a0ahttps://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1155
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.
Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.
For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1154
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
