The `state-set` signal is emitted to change the underlying state,
which can have two reasons:
1. the user toggled the switch
2. the extension's `enabled` state changed externally
In the second case, calling enable/disable is pointless at best,
and can mess up the expected state by permanently disabling an
extension that was disabled because of the global kill switch.
Address this by only calling enable/disable if the new state does
not already match the current value of the `enabled` property.
Close https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7305
Fixes: fec523f83f ("extensions-app: Use new 'enabled' property")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3090>
The switch for enabling/disabling extensions currently bases its
state on the extension's ACTIVE state.
This is problematic in the enabled-but-inactive case, because
activating the switch tries to change the state from off to on,
which leads to enabling an already enabled extension (an obvious
no-op).
The new `enabled` property allows us to do better, and use delayed
state changes where the switch position represents the `enabled`
state, and the trough color whether the extension is ACTIVE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
The ENABLED state means that an extension's `enable()` method
was called successfully.
This usually matches whether an extension *should* be enabled
according to the enabled-extensions/disabled-extensions settings,
but not necessarily: If an extension had an error or does not
support the currently active mode, its actual state is different.
We currently only expose the actual state to external tooling,
but whether an extension should be enabled is relevant as well,
for example to disable a lock-screen only extension from the
regular session.
For that purpose we will expose a separate `enabled` property.
To avoid confusion with the existing states, change the exposed
names to (IN)ACTIVE.
This does not affect the D-Bus API, as the numeric values of
the states remain unchanged.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
Manually adding and removing rows to dynamic lists is rather
old-fashioned, GTK 4 strongly encourages the use of models.
Modernize the code by exposing extensions as ListModel, and
bind it to the two lists with appropriate filters.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Most properties that determine the availability of an action are
not expected to change, but now that extensions are represented
as a GObject, we can just generically set up bindings for all
actions instead of explicitly tracking the properties that we
expect to change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Both icons are not immediately obvious, and the context provided
by the tooltip can be hard to discover.
Address this by making the icons interactive, and provide further
information in a popover.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3051>
The extensions site recently added support for a custom
"version-name" string in metadata:
gitlab.gnome.org/Infrastructure/extensions-web/-/merge_requests/154
This allows developers to control the version that is exposed to
users. As the version according to the developer is almost always
more relevant than the automatic version assigned by the website,
use it instead of the "version" field if set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2995>
We currently include a fake config.js file to satisfy the indirect
import from ExtensionUtils. However we're about to need to pass
build-time information into the program ourselves, so generate
a proper file.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2841>
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
libadwaita has a new About window, and GNOME apps are expected
to use it going forward instead of GtkAboutDialog.
Comments are meant to be detailed, and are no longer shown in the
main view. So we remove the old comments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2373>
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
If the finish function isn't specified, promisify will now try
to use the async name without '_async'/'_begin' suffix (if any)
and '_finish' appended.
Everything except IBus uses a variation of that pattern, so there's
quite a bit of boilerplate we get to remove…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2174>
Replace deprecated functions with their direct replacements:
- dep.get_pkgconfig_variable() → dep.get_variable()
- prg.path() → prg.full_path()
- source/build_root() → project_source/build_root()
In one case we need meson.global_source_root() that was only
added in meson 0.58, so bump the requirement to that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2077>
