Commit d76162c1c0 removed the ability to pass an extension UUID to
the Extensions app, when we moved the dialog to a portal and made
gnome-shell use it instead of spawning the extensions app.
However that missed that many extensions called out to the app to
open their own prefs.
While extensions are encouraged to switch to the new openPrefs()
convenience method added in commit 8030d9ad32, restore the old
behavior with a small script under the old gnome-shell-extension-prefs
name that either calls out to the portal or launches the app.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
This is a moderately fast two-pass gaussian blur implementation.
It downscales the framebuffer dynamically before applying the
gaussian shader, which cuts down rendering time quite considerably.
The blur shader takes 2 uniforms as input: the blur radius; and
whether to blur vertically or horizontally.
The blur radius is treated as an integer in C land to simplify
calculations. The vertical parameter is treated as an integer by
the shader simply due to Cogl not having proper boolean support
in snippets.
At last, brightness is also added to avoid needing to use an extra
effect to achieve that. Brightness is applied in a different pipeline
than blur, so we can control it more tightly.
ShellBlurEffect also implements a "background" mode, where the contents
beneath the actor are blurred, but not the actor itself. This mode is
performance-heavy.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
The gnome-extensions tool code is really independent from the rest of the
code base, and could be used either as part of the gnome-shell build or as
stand-alone project (for example for the extension-ci docker image).
We can actually support both cases by moving the code to a subproject.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
gjs now relies entirely on introspection data to determine parent
types and implemented interfaces, so in order to have all methods
and properties resolve correctly, we must include the corresponding
GIRs of all types used.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/574
Using a single resource file for all JS sources saves a couple of
build system instructions, but has some serious downsides:
- bundling the entire shell code with the tools blows
up their size unnecessarily
- the tools are rebuilt unnecessarily for any shell
code change
Autotools was painful enough to let this slip, but with meson we
don't have any excuses - using the actual dependencies speeds up
the build a tiny bit and reduces the tools' sizes from over 2M
to about 50k.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/192
Simply reusing the same dependencies as gnome-shell itself not only
means that we link tons of stuff unnecessarily, but also that we
have to do the whole mutter rpath dance for nothing. Just use the
dependencies those executables actually need for a nice cleanup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/192
So that we can be started by systemd --user, instead of gnome-session.
There are three units:
- gnome-shell.service: Start gnome-shell itself.
- gnome-shell-x11.target, gnome-shell-wayland.target: Sync points for
units that need to care if x11 or wayland is in use.
gnome-settings-daemon will use these, for example.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/138
Meson now warns when specifying the rpath in linker flags instead
of using the newly added build_rpath option - now that we already
depend on the latest release, there's no reason anyway to not use
the nicer syntax.
https://bugzilla.gnome.org/show_bug.cgi?id=786343
We cannot rely on any build order, except the one we specify ourselves.
St depends on various generated files; other targets depend on those
files existing, so they can be included. There is no direct relationship
between targets and files, unless we declare a dependency, using the
Meson declare_dependency() constructor — which allows us to replace the
various `link_with` directives with the more appropriate `dependencies`
one, and also allows us to specify sources that must exist by the time
we build those targets.
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
