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
When building the list of window PIDs, it's possible Mutter doesn't know
about the PID the client has and meta_window_get_pid() will return 0. We
should handle this case by not adding the PID to the list of PIDs
instead of adding an invalid one to it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
MetaWindows get_pid() API changed to use the client PID, which also
works for Wayland clients instead of only X11 clients now. This API
returns 0 instead of -1 for invalid PIDs, so update our check according
to that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
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
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
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
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
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
Commit 4589da957 added D-Bus API for enabling/disabling extensions,
use that if possible to provide better feedback and not clutter the
settings with non-existent UUIDs.
The old code path is preserved as fallback to keep the commands
working from outside a running shell session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
UninstallExtensions() only returns whether the operation was successful,
not why it failed. However we know that only user extensions can be
uninstalled, so check that first to provide a more meaningful error.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
For the prefs command, we first fetch the extension info to check
whether the extension exists and actually has preferences. This
pattern can be useful for other commands and properties, so split
out a generic helper function.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
Error reporting is useful when used interactively, but often undesirable
when used in scripts. Account for that with a common --quiet option,
which is more convenient than redirection stderr to /dev/null.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
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
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
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
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
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
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
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
