When there is a transition, it's likely that we are animating some part
of the desktop, and in such situations we don't want to unredirect
fullscreen windows.
This fixes unwanted unredirection when e.g. hiding a modal dialog by
re-enabling the unredirection after the animation has finished, instead
of when it starts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/721
Updating the window list in the Looking Glass is a costly
operation: it destroys a whole lot of actors, and recreates
them. This triggers CSS changes, repaints, and allocations.
It is specially bad when paired with Wayland's big number
of window creations and deletions when showing Builder's
and Epiphany's popup window.
Only update the window list in the Looking Glass when it is
visible.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/719
Since ES5, it is possible to create objects with no prototype at all:
let foo = Object.create(null);
Those object won't have any builtin properties like hasOwnProperty(),
which is why eslint added a corresponding rule to its default rule set.
While this isn't an issue that affects our code, there's no harm in fol-
lowing the recommendation and call the method through Object.prototype.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
We currently use no less than three different ways of indenting
object literals:
let obj1 = {
foo: 42,
bar: 23,
};
let obj2 = { foo: 42,
bar: 23 };
let obj3 = { foo: 42,
bar: 23
};
The first is the one we want to use everywhere eventually, while the
second is the most commonly used "legacy" style.
It is the third one that is most problematic, as it throws off eslint
fairly badly: It violates both the rule to have consistent line breaks
in braces as well as the indentation style of both regular and legacy
configurations.
Fortunately the third style was mostly used for tween parameters, so
is quite rare after the Tweener purge. Get rid of the remaining ones
to cut down on pre-existing eslint errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Since disabling an extension will lead to disabling and re-enabling all
following extensions in the list, always disable multiple extensions by
looping through the list in reverse order.
This lowers the execution time of the event handlers quite a bit if many
extensions are installed.
Thanks to Philippe Troin for identifying the problem and proposing the
initial patch to change the extension order when reloading.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/177https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Only push uuids of newly enabled extensions to the `_extensionOrder`
array if enabling them was successful.
Otherwise, since `_callExtensionDisable()` doesn't remove uuids that
weren't successfully enabled from the array, those extensions get added
to the array multiple times when they're disabled and enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
It's currently possible to circumvent the `sessionMode.allowExtensions`
property: For already enabled extensions one can call reloadExtension
via DBus, for new extensions it's possible by adding the extension to
the enabled-extensions gsettings key and setting the
disable-extension-version-validation key (which triggers a reload of
`this._enabledExtensions`) and then calling reloadExtension via DBus.
So to enforce `allowExtensions` while still allowing to update
extensions and keeping the extensionSystem synced with various gsettings
keys, replace the checks for `this._enabled` with simple checks for
`Main.sessionMode.allowExtensions` inside `_callExtensionInit()` and
`_callExtensionEnable()`.
The remaining checks for `this._enabled` are only small optimizations to
prevent running code on irrelevant sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Right now we're only handling added sessionMode extensions correctly on
sessionMode updates, also handle the other case and disable removed
sessionMode extensions on sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Instead of only logging a message that loading the extension stylesheet
failed and silently returning we should use `logExtensionError` for that
instead. This also sets the extension state to ERROR and makes sure we
don't try to enable it again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
If the extension doesn't exist in the `this._extensions` Map, we'd try
to access `extension.dir` on undefined/null. So set the `dir` variable
after checking if `extension` is defined.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Code and comment were based on the old get_input_rect() and get_outer_rect()
method names that were changed to the more appropriate get_buffer_rect() and
get_frame_rect() a long time ago.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/713
The animation was removed in commit 6a00a504d4 for consistency with
other menus. However commit a9b12d5d73 then *added* animations to
those just four minutes later.
So add back the original animations for consistency, both with menu
closing and with other menus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1595
Remove transitions of the `slide-x` property of the layout manager
before we set the property to a fixed value, otherwise the transitions
might still be running and change the value after we set it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/707
When selecting an area for screenshot we monitor the events while we've valid
coordinates in order to redraw the rubber band.
However, we don't stop ignore the motion events after button release and so
while animating. This might cause an unwanted effect if moving the mouse away
during fade out that is way more visible slowing-down the animations.
To fix this ignore any motion event once we've set the results.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/711
Add a new popover with a regular entry + button to rename
folders. The layout is similar to other GNOME applications.
The popup is implemented as a PopupMenu subclass, leaving
the grab management to PopupMenuManager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/675
We disable and enable extensions inside the `notify::active` signal
handler, but we shouldn't do that in case the change didn't come from
the user but because something else changed the state of the extension.
This causes an issue when the extensionPrefs window is open and the
session gets locked: The extensions are temporarily disabled by the
shell, extensionPrefs updates its switches on the state change and adds
those extensions to the `disabled-extensions` gsettings key inside the
signal handler. Now when the session is unlocked again, the extensions
won't be enabled again since they're forced-disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/705
We're using a vfunc override for `get_paint_volume` to exclude children
with an opacity of 0 from the paint volume and thus decrease the size of
the area we need to paint.
Now if the paint volume is requested during the spring animation (the
real icons are hidden using an opacity of 0 and clones are used for the
animation), `get_paint_volume` returns a paint volume with a height of
0. After that, the spring animation finishes and the icon-opacities are
set to 255 in `_resetAnimationActors`, and since we cache paint volumes
and there's no reason for Clutter to assume it got invalid, the icons
end up not being painted.
Fix this by queuing a relayout of the grid when the opacity of a child
is changed from or to 0, which manually invalidates the paint volume.
The reason why this is not an issue with the paginated icon grid
(all-apps view) is probably because StScrollView invalidates the paint
volume a lot more often than regular containers.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1502
Extensions might emit JS errors explicitly or implicitly, however GNOME
Shell doesn't present any stack trace for those making them quite hard
to debug.
Make this easier by logging errors with logError() whichs includes the
stack dump.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/700
