Turns out it's not that clear in which cases we want to apply updates
and in which ones we shouldn't. For example one case is when the device
is running on battery, where we currently display a warning, but still
install updates by default.
So let's revert that again for now and hopefully work out a proper
concept for updates in the future.
This reverts commit ddb85c03c3.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1228
When a modal that's not on top of the modalActorFocusStack gets popped,
we shift the focus stack as described in popModal() to ensure the chain
remains correct. That however destroys the association of a modal actor
and its prevFocus actor on the focus stack, because the prevFocus actors
are now moved to different entries of the stack.
Now when a prevFocus actor gets destroyed, we don't handle that case
correctly and search for the modal actor that was associated with the
prevFocus actor before the stack was shifted, which means we end up
unsetting the wrong prevFocus actor.
So fix that and search the stack for the prevFocus actor which is being
destroyed instead to unset the correct entry.
Thanks to Florian Müllner for figuring out the actual issue and
proposing this fix.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2446
(cherry picked from commit d3880c0bff)
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
(cherry picked from commit 8d139bbd95)
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
(cherry picked from commit fb1bb291eb)
Just as with the last commit, we should not break the assumption made by
Clutter that parents have their allocation set before their children get
allocated, so fix that here, too.
In this case we have to fix it by chaining up to the parent vfunc
override and updating the allocation once more before allocating the
`this._label` child.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
(cherry picked from commit 49d6db34b7)
It's important to update the allocation of the parent before allocating
its children, it's an assumption we make in a lot of places.
This broke resource scale calculation for boxpointers and their
children when multiple monitors with different scales are used and the
primary monitor is not positioned at x=0, y=0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
(cherry picked from commit 63a0e521fd)
The workspace switcher blocks state updates while the indicator is
animating. Since commit 9c1940ef9d the indicator is considered to
be animating when the workspace adjustment's value doesn't equal the
active workspace.
There is one case though where this breaks badly: When a workspace
is inserted before the active one, the adjustment's upper and value
properties are changed without transitions. But if that change happens
while there's an ongoing transition to the previously active workspace,
the value gets out of sync with the active workspace and we end up
blocking state updates indefinitely.
Fix this by removing any transitions before setting the adjustment
value.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2625
(cherry picked from commit 2e80995f19)
We override the :visible property for the keyboard actor, but don't
provide a corresponding setter. The property is therefore read-only
on the javascript level, and any attempt to set it will fail.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2691
(cherry picked from commit 3ba4304da9)
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
(cherry picked from commit b191e9ef91)
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
(cherry picked from commit f4d90bc127)
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
(cherry picked from commit 3fac0632a8)
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
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
(cherry picked from commit fbe2e30f38)
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
(cherry picked from commit 45bc850715)
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
Commit 83c6b2ab promisified the method in endSessionDialog, which means
that after the module is imported, every caller will get the promisifed
version. That can be a bit surprising in completely unrelated modules,
so commit 764527c8 (on master) moved the promisification of more common
methods into environment, as that's initialized early and expected to be
shared between anything else.
Do the same for the call() method on the stable branch.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
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
(cherry picked from commit a0def23940)
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
(cherry picked from commit f49b58cf97)
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
Set the do not disturb label as the label actor for the do not disturb switch,
so that Orca speaks the do not disturb label when the user moves
keyboard focus to the do not disturb switch.
Also enable toggle mode for the "Do Not Disturb" button and bind it's checked
state to the state property of the switch. This makes sure that Orca presents
thecorrect state of the do not disturb switch to the user.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2508
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Since commit 2894085c45 we omit sound feedback on volume changes
if something is already outputting sound. Unfortunately that
"something" may be our own feedback (from a previous volume
change).
In that case we do not want to omit the new feedback, so instead
cancel the previous one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1147
The offset argument is changing from uint to int. Which means we
might would pass a negative offset and trigger an "out of bounds"
error. Make it work more or less alright with older mutters, by
clamping the offset to 0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1146
Since commit 784c0b7e4 we use the name of the nearest city rather
than the weather station, as the latter tend to have unwieldy
and weird names.
However the nearest city may not be that near after all, in which
case the result is again surprising.
Address this by not using the nearest city name unconditionally, but
only if it appears in the station name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2468
AuthPrompt is created on demand, and this._authPrompt is
expected to be null except on very strictly controlled
occasions. The idle monitor callback isn't one of them.
Check if AuthPrompt exists before cancelling it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2371
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
We include config.js because it is a dependency of ExtensionUtils,
but it's not actually used in the code paths we exercise.
As we want to allow stand-alone builds of the app, it is much easier to
fake the module than to either include a generated file from elsewhere
in the tree or generate it ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
Instead of adding a dragMonitor for every icon in the grid as soon as
one icon is getting dragged, only add a dragMonitor for the icon that is
currently being dragged over (ie. the current drag-target). With a large
number of icons in the iconGrid, this should significantly reduce lags
while dragging.
We can do this by detecting the DnD-entering of an icon or folder using
the `handleDragOver()` callback of drag-targets, adding the dragMonitor
because we know an icon is hovering above the drag-target and then
detecting the DnD-leaving of the drag-target by using the `dragMotion()`
handler, where we remove the dragMonitor again as soon as the
targetActor is no longer our actor (ie. the drag-target).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While it should be impossible to destroy a FolderIcon while a DnD action
is still going on, there might still be rare cases where this happens
(ie. when a folder is removed because an app got deleted during DnD).
So make sure we're on the safe side here and don't potentially leave
dragMonitors around after the icon is destroyed by removing the
dragMonitor inside the onDestroy handler of the FolderIcon, just like we
do for AppIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
Forward the arguments at the 'delete-surrounding-text' signal
from IBusInputContext to clutter_input_method_delete_surrounding()
so that ibus-typing-booster use the deleting surrounding text function.
Input method engines can delete the output text in applications
with this function.
This change will require a change of mutter of mutter!517
because the first arguemnt of the 'delete-surrounding-text' is INT
to express the offset of the current cursor position but
the first one of clutter_input_method_delete_surrounding() is UINT
since the Wayland spec accepts UINT in delete_surrounding()
mutter will change the type of the first one to INT in
clutter_input_method_delete_surrounding() to work with this change.
https://gitlab.gnome.org/GNOME/mutter/issues/539https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/477
While we don't technically need the app to download and apply
updates, we do require it for notifying the user about available
updates and listing extensions with pending updates.
So instead of intransparently applying updates in the background
without the user noticing, disable updates altogether if the
Extensions app is not installed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2346
Blacklist support was added all the way back in commit 1e286e43, but
the code had been defunctional until recently. While uninstalling an
extension that has been blacklisted makes sense off-hand, unfortunately
we don't know if an extension was *actually* blacklisted:
The website returns that operation for any extensions for which it
doesn't find any versions that match the shell version. That is, the
most likely reason is that the user updated to a new GNOME release
which the extension doesn't support yet.
It doesn't look like the website is going to change that behavior any
time soon[0], so drop the 'blacklist' handling for the time being.
[0] https://gitlab.gnome.org/Infrastructure/extensions-web/-/issues/95https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1132
Commit 55b57421d changed signal handlers to the corresponding vfuncs,
but didn't always chain up as necessary. In most places this doesn't
matter, but at the very least the commit broke activating message list
items via the keyboard.
Add all (hopefully) the missing chain-ups to get the expected behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2319
Destroying the policy invalidates it, so accessing it from a
Source::destroy handler (for example to disconnect signal
handlers) currently results in warnings like:
Object .Gjs_ui_messageTray_NotificationApplicationPolicy
(0x7f8c7c0a64a0), has been already deallocated — impossible
to access it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2238
Since PackageKit 1.11.1, the prompt to install updates on the end
session dialog has been (mostly) broken. The problem is that it only
works if PackageKit is running at the time the end session dialog is
opened; otherwise, our GDBusProxy has invalidated all of its properties,
which we read to see if update is possible. We need to autostart
PackageKit before reading its properties to fix this problem. That would
be easy if we were calling a method to see if an update or distro
upgrade were available, but since we're just checking a property, using
cached properties won't suffice. We'll have to manually check the
property value to ensure we autostart PackageKit.
Most of the code is written by Florian. Thanks Florian!
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2276
Previously we'd show the system background and then wait till the
main loop was idle before beginning the shell startup animation.
This resulted in one initial frame that was always just the system
background.
Now we try to get both the system background and the startup animation
begun on the same first frame.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1102
In telepathyClient we consider messages both Tpl.TextEvents and
Tpl.Messages, and we manually create JS objects to copy the properties we
care for each one. This may lead to objects not matching the interface we
want.
Instead, use an object with construct-only properties and two factory static
methods to initialize it.
Unfortunately we need to use the ChatMessageClass for the class name or
calling the static methods would trigger a gjs error as per [1].
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1113
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/310
We now warn on startup if screen locking isn't available, however for
users who choose not to use GDM or logind, repeating the warning on
each login is more annoying than helpful.
Instead, limit the warning to the first login on which the screen lock
became unavailable. That way the notification will still serve the
intended purpose of informing the user, but without being perceived
as nagging.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
It's easy to forget to add a new <release> tag to the metainfo when
doing a new release.
Address this with an additional test if appstream-util is recent
enough to include the new validate-version command, so distcheck
fails when the metainfo wasn't updated.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1117
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
As outlined earlier, in order to turn the Extensions app into a properly
sandboxed application, we need to split out the extension prefs dialog
and move it elsewhere.
With "elsewhere" being the new Extensions D-Bus service, effectively
turning it into a shell extensions portal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
We are jumping through quite some hoops to support showing only the
preference dialog when given a UUID on the command line.
As gnome-shell is about to stop calling out to us for the prefs dialog,
the reason for supporting this is going away, so remove all the special
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
The dialog that contains the extension's preference widget has become
fairly complex over time, mostly due to the error handling.
It therefore makes sense to move it to a template, just like we did
for the main application window and extension rows.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
On X11, _onFocusChanged() updates the input region, as well as the
reactive-ness of the dialog's buttons.
That method is not only used as signal handlers (which are correctly
disconnected when the dialog is hidden), it also runs when the "show"
transition completes.
That's a problem if the transition is still ongoing when the dialog is
hidden, as it will then only complete when it is replaced by the "hide"
transition, after the this._dialog has been reset to null, and trying
to access the dialog's buttons results in an error.
Avoid this by explicitly removing all transition on hide before
resetting the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2467
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Detailed notifications are meant to be single line, just as unexpanded
notification banners. So handle them the same way as in the message
list, and replace embedded newlines by spaces.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2463
We only show the list of system- and user extensions if corresponding
extensions are installed, however we only update the visibility
after loading the initial list of extensions.
As it's possible for the first user extension to be installed while the
app is open or the last one to be removed, we should also update the
list visibility after extension state changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1088
While we only shut down after a method call completed or (if the
interface has signals) the sender disconnects from the bus, services
may need to inhibit auto-shutdown for more specific reasons themselves,
for example when a method call kicks off an operation that should
complete before shutting down.
Add hold() and release() methods like Gio.Application for those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1115
Some timezones, like the one of Kathmandu don't only have hour-based
timezone offsets, but their timezones are also offset by minutes. So
instead of showing weird values like "+5.8", show the minutes properly
in a format like "+5:45".
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2438
I misremembered that imports.package.start() would set up the correct
gettext domain, but the module only provides a convenience method
for doing that.
Use it to bring back translations in the Extensions app, whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1108
Now that the org.gnome.Shell.Extensions interface exposes the
disable-user-extensions setting on D-Bus, we can use that instead
of the shell's GSettings.
In a future where we distribute the app separately as flatpak, this
will require one less hole in the sandbox.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Using the "regular" loadInterfaceXML() helper means less code duplication,
but it also ties us to the resource used by gnome-shell.
In order to untangle the extension app from core gnome-shell, change that
to load the interface from the existing data resource instead. While that
does involve reimplementing loadInterfaceXML(), it's not too bad actually
with the resource-loading code stripped (as the data resource is already
loaded by the package module).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Extension updates are installed at startup, so any errors that bubble
up uncaught will prevent the startup to complete.
While the most likely error reason was addressed in the previous commit
(pending update for a no-longer exitent extension), it makes sense to
catch any kind of corrupt updates to not interfere with shell startup.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
When an extension is uninstalled, there is no point in keeping
a pending update: If the update didn't fail (which it currently
does), we would end up sneakily reinstalling the extension.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
Doing blocking IO in a graphical UI is bad, doing it in the compositor
is much much worse. So even if handling VPN requests is a relatively
rare event, doing it asynchronously is better.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
checkForUpdates() will currently always query the server for updates,
even when passing an empty vardict of installed extensions. We know
there won't be any updates in that case, so avoid a pointless network
request.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1100
There are two ways for applications to provide a high contrast icon:
1. install an icon into the HighContrast theme
2. install a symbolic icon into the default hicolor theme
The latter is preferred nowadays, and implemented in the high-contrast
CSS variant by enforcing the symbolic icon style.
However together with the way we currently enable/disable high-contrast,
this can lead to the following race:
1. the GTK theme is changed from HighContrast
2. we reload the default stylesheet
3. the icon style changes to "regular", so we request a
new icon from the HighContrast icon theme
4. the icon theme is changed from HighContrast
5. we evict existing icons from the cache
6. we reload icons for the new icon theme; however as we
find a pending request (from 3), we re-use it
7. the request from 3 finishes, and we end up with a
wrong icon in the cache
The simplest fix is to change the icon theme before the GTK theme: Unlike the
theme name, the icon style is encoded in the cache key, so we won't re-use
an old (and incorrect) request in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2414
The SignalQuality property is defined on the GDBusProxy, not the modem
JS object.
Fix this runtime warning:
JS WARNING: [resource:///org/gnome/shell/misc/modemManager.js 252]: reference to undefined property "SignalQuality"
JS ERROR: TypeError: this.SignalQuality is undefined
_reloadSignalQuality@resource:///org/gnome/shell/misc/modemManager.js:252:34
_init@resource:///org/gnome/shell/misc/modemManager.js:234:14
NMDeviceModem@resource:///org/gnome/shell/ui/status/network.js:517:34
_deviceAdded@resource:///org/gnome/shell/ui/status/network.js:1755:27
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1097
When launching the default calendar application, we special-case
evolution to make sure it starts up with the calendar component.
This is currently broken in two ways:
- evolution changed its .desktop file to use reverse DNS notation
- as evolution can now be distributed via flatpak, we can no longer
assume that 'evolution-calendar.desktop' exists when evolution does
(even though we ship the .desktop file ourselves, it is considered
invalid if the executable isn't found)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1093
