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>
With the previous preparations in place, it is time to take the plunge.
As both the app and the portal use the same small library for handling
external windows, port everything at once to avoid the hassle of building
and installing two versions of the library.
With the portal using GTK4 now, all extensions must port their preference
widgets as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
Unlike in previous GTK version (or Clutter), destroy() no longer
breaks reference cycles but just releases the reference held by
GTK itself.
So any reference we hold - either the explicit property or any signal
handlers that bind the window as `this` - prevents the window from
being disposed when closed, and the application won't quit.
Work around this by explicitly running dispose() on the window when
it is removed from the application.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
Currently there is no indication that an extension had an error except
for the sensitivity of the switch (which may have a different cause).
This is useful information to users, so add a small error indicator
alongside the updates icon and show the actual error in the details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
Currently the switches handle position reflects the requested
extension state (as in: the user (de)activated the switch),
while the actual extension state is reflected by the underlying
state.
That doesn't work well when the switch is insensitive though (for
example on error), because the desaturation neuters the color
that reflects the state.
Address this by resetting the switch handle to the state when
making it insensitive.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1263
We kept the old binary name when overhauling the tool for the Extensions
app to avoid unnecessary churn for packagers/distributors.
However we now have a reason to "free" the old name, so rename the binary
to match the (sub)project name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
