Just like StIcon does, we should use a container widget for the fallback
app icon that we get using the cairo surface property. It's needed
because the widget returned by shell_app_create_icon_texture() can be
resized freely, while we want the aspect ratio of the actual texture to
remain the same.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2578
(cherry picked from commit 85846d88f0)
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
(cherry picked from commit bc973b80d7)
Now that the extension preference dialog is opened by a separate
D-Bus service rather than the Extensions app, it can be opened
without a parent window that provides name and icon.
Fix this by adding back a hidden .desktop file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2562
(cherry picked from commit 6b7c85b079)
Predefined categories aren't a great way for organizing installed
applications, but they have their use in "stores" like Software
or flathub.
Not listing any category means we fall through the cracks, so
pick the (hopefully) least inappropriate one ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1160
(cherry picked from commit 360f5b1642)
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
(cherry picked from commit 07deda593a)
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)
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
(cherry picked from commit 7ff7fb5d3b)
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
The app-cache code currently stores the folder translations in a hash
that can be accessed via shell_util_get_translated_folder_name().
This hash uses the filename (inc. extension) for the "desktop-directory"
as key which causes an issue when trying to find the translation
on AppDisplay._findBestFolderName() which gets categories (folder names)
from the app info which doesn't contain the ".directory" extension.
Fix that by storing the filename without extension as the hash key for
the cached folder translations.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1168
(cherry picked from commit 343b3351f1)
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
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
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
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
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
