widget.get_effect(...) can return null while locking the screen, resulting
in a TypeError. In this situation the screen ends up black with a cursor
but never going to sleep, and moving the mouse brings the old screen
contents up but does not allow unlocking.
unlockDialog.js assumes that widget.get_effect will return non-null,
but other places such as getWindowDimmer in windowManager.js go out of
their way to be more careful.
[smcv: Add commit message, remove hard tabs, add missing semicolon]
Resolves: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3071
Bug-Debian: https://bugs.debian.org/968440
The framebuffer we use for rendering shadows is scaled by the resource
scale, that means we also need to offset coordinates when translating
them to the framebuffers coordinate system.
So far we forgot to do that when translating the framebuffer using the
position of the actor, which lead to small rendering bugs of
text-shadows for actors allocated at non-zero origins. To fix that,
simply multiply those positions with the actors resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1390
This fixes an issue where the indicator can be out of sync until the
RfkillManager (used by it) properties change.
The problem is that multiple instances of the indicator will use
the same RfkillManager instance (getRfkillManager() returns a singleton)
that only guarantees to emit the changed signal in two scenarios:
when the D-Bus proxy connects and when the proxy properties change.
If by the time an indicator is instantiated the RfkillManager's D-Bus
proxy is already connected, that indicator would only sync its state
when the RfkillManager properties change.
Let's fix that by always syncing the state on construction - in the worst
case scenario the RfkillManager's D-Bus proxy won't have connected yet
and the indicator state will be temporarily out of sync but once it gets
connected the indicator will sync again with the correct state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1386
While we do have some handling for removing the active menu, it has
been a no-op for years. The bit that we really care about from the
PopupMenuManager's point of view is the existing grab though. Drop
that instead of calling _closeMenu() directly; ungrabbing will still
call the method indirectly, and it will still be a no-op :-)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3022
On X11, clients can grab keyboard on pointer (for example for popup
menus), and as a result the pushModal() call when opening the overview
fails.
However when the hot corner was used to toggle the overview, we still
show the ripple animation in that case, which is confusing as the action
did not actually happen.
Fix this by only showing the ripples if the overview is animating after
calling toggle(), as that should be a reliable indication of whether
the call was successful.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3005
AppFolderDialog was calling adaptToSize from its alloc vfunc, which
changed the spacing of the icon grid after its size used to calculate
the adjustment for scrolling had already been determined. This was
resulting in the app folder not being able to scroll all the way to the
end the first time it has been opened.
Fix this by scheduling a relayout. This however can not be done
immediately after the adaptToSize call on the iconGrid, because this is
called from within an alloc vfunc. So instead use Meta.later_add to
ensure it gets called after the alloc, but before the next redraw.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2535https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1378
Now that the icons are correctly scaled down and don't cause overlaps
with the spacing anymore, the spacing between icons causes them to be
smaller than they were before. This only affects low resolutions,
because the spacing property is used as a minimum spacing for the app
grid. On higher resolutions the spacing is always larger than this
minimum.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1375
At the moment, if a user switches to the login screen vt,
the login screen fades in whatever was on screen prior, and
then does a reset.
It makes more sense to reset first, so we fade in what the
user is going to interact with instead of what they interacted
with before.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2997
(cherry picked from commit 13137aad9d)
This reverts commit 67b9386b4b.
For not yet known reasons this caused a regression on the stable branch. Further
more it appears not to be needed, as no work depending on it has been backported
so far.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2971
This reverts commit bda8ba5ed1.
For not yet known reasons this caused a regression on the stable branch. Further
more it appears not to be needed, as no work depending on it has been backported
so far.
As backgrounds are cached, it is possible that we never emit the
'loaded' signal added in commit f386103bc1. We are relying on the
signal though, so do the same as Background and emit the signal
from an idle if the background was already loaded.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1371
(cherry picked from commit 5c550daecb)
Currently, the login animation can occur before the user's wallpaper has
been loaded. When this happens, we wind up displaying a solid blue
background for half a second or so before the proper background is
displayed. This looks jarring and bad. It's great that we can start
GNOME quickly, but starting up before the wallpaper is ready is *too*
quickly.
I've been meaning to fix this since 2014. Better late than never! We can
just have BackgroundManager emit a loaded signal the first time it loads
its first background, and have the startup animation code wait for that
before proceeding.
Some of this code is by Florian, who helped with promisifying. Thanks!
https://bugzilla.gnome.org/show_bug.cgi?id=734996
On Wayland, navigating menus with the keyboard would not open drop-down
menus when NumLock is enabled.
That's old issue (gnome-shell#550) that was not completely fixed with
commit 88556226 because the lock mask needs to be filtered out in
_onKeyPress() as well.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/550
_updateIconSizes() was assuming that the icon is the only content of
an item when scaling the icon size to ensure the item size matches
_fixedHItemSize/_fixedVItemSize. However the icon may have padding and
there might be a label and spacing between the icon and the label. This
resulted in items being larger than their slots.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2234
The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
While GtkIconTheme does look up icons in the toplevel icons resource
path, it will only use them as ultimate fallback. That is, if the
icon theme (or the hicolor fallback) include a "keyboard" icon, it
will be used over the "keyboard-enter-symbolic" icon in the resource.
Moving the icons to appropriate subdirectories gives them higher
priority than the fallback names, and thus fixes the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2631
Since commit b60836932 we only allow WM_CLASS matches for sandboxed
applications if the found app's ID is prefixed by the sandbox ID.
The existing check still has a hole in it though: "org.example.Foo"
and "org.example.FooDevel" are different applications, yet the former
is a prefix of the latter.
So tighten the check by including a trailing "." in the checked prefix;
this excludes cases like the above, while still working for the regular
case of a single .desktop file because our app IDs include the ".desktop"
suffix.
Spotted by wjt.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1357
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
The arrow of the removed app was still left in the list with the
visibility of the arrow still depending on the original list order. This
could either lead to apps with just one window now suddenly having a
down arrow or apps with multiple windows not having one. If the last
window in the list had a down arrow, it would have been displayed
outside the window switcher.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2935https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1340
In portrait orientation, we set the height to the preferred height
for the monitor width (or, if smaller, a third o the screen height).
However as the forWidth currently doesn't make a difference, the height
is effectively controlled by the natural height of the keys - which is
rather small.
Address this by making AspectContainer request an appropriate preferred
size based on the fixed ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2349
Currently our heuristics for matching a window to its app check
for the application ID before the WM_CLASS, as the ID is more
reliable in so far that it is outside the application's control
and so it cannot use it to spoof a different application.
However this also prevents applications with multiple .desktop
files like LibreOffice from matching any .desktop files other
than the one under the main ID.
Since we now no longer allow the WM_CLASS to match a .desktop
file that doesn't belong to the sandboxed application, we can
fix that issue by checking the WM_CLASS first, without opening
the door to spoofing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
At least flatpak (no idea about snap, sorry) enforces that all .desktop
files exported by a sandboxed app use the application ID as prefix.
Add the same check when trying to find a match based on the WM_CLASS,
to prevent sandboxed apps from matching a .desktop file they do not
own.
At the moment this is unlikely as we check for a match on the
sandboxed app ID first, but we are about to change that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
As usually with GObject setters, we should check whether the property
actually changed before setting the value and notifying the property. So
check whether the title or description text actually changed before
setting it.
This fixes a bug which makes the title flicker and change its size,
because when updating the title we remove the "leightweight" css class
and reapply it inside a later, which makes the title appear larger for
one frame.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1336
When scrolled, the container's allocation is smaller than the allocation
of the content. To account for that, commit 2717ca9d08 added the
additional size reported by the layout manager to the content allocation.
However as it did so unconditionally, we now allow children to extend
outside the parent even when *not* scrolled, which breaks any constraints
set on the container (like "width" or "max-height").
Fix this by only extending the child allocation in scrollable dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2491
The blur effect needs to take the scale-factor into account, so we
listen for scale changes. However we set up the signal handler when
creating a background, which is repeated for each monitor, and every
time the monitor configuration changes. But we only disconnect the
last handler that was connected, and only when we are destroyed,
not when recreating backgrounds.
Fix this by splitting out updating the effect parameters to a separate
method that iterates over all backgrounds, so we can simply set up the
handler from the constructor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1341
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
