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
In order to support OpenExtensionPrefs()'s parentWindow parameter,
we will need the ability to make a window transient to an external
window identified by a string handle.
This takes the corresponding code from xdg-desktop-portal-gtk and
brings it into an introspectable form, likewise the counterpart in
libportal to export a string handle for a GtkWindow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1087
I always forget to keep the extension-tool version number in sync when
doing a new release. Given that it's unlikely that I'll do much better
in the future by myself, make distcheck fail when the versions don't
match.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1076
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This is what most GNOME modules now use instead of a shell script,
which makes sense given that the build system itself is written
in python.
This particular copy comes from nautilus ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/920
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
Make gjs to compute the GType name for registered GObject-derived
classes using the file basename and the first directory name, so that we
can avoid name clashing, and ensure that no extension will break the
shell by registering a name that is already used (by the shell or by any
other extension).
This requires gjs commit 02568304 [1] that will be part of release 3.35.2,
so bump the required version as gjs does post-release version bumps.
[1] https://gitlab.gnome.org/GNOME/gjs/merge_requests/337https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/790
Extensions are uploaded to extensions.gnome.org as zip files that
not only contain the extension sources, but also compiled GSettings
schemas and message catalogues. To make this more convenient, add
a corresponding command for creating an archive suitable for up-
loading.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
While we don't actually require a more recent version at build time,
we do need the latest stable version at runtime. There's no strong
reason for making that differentiation, so bump the requirement.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1006
The browser plugin is crashy and broken; there are dozens of bugs filed
against it on Bugzilla and nobody is looking at them. Chrome and Firefox
have both dropped support for NPAPI plugins. Epiphany still has support,
but it's hidden behind a gsetting and all the UI to enable it has been
removed, so very few users would be able to figure out how to enable.
I've even previously considered blacklisting this plugin in the past due
to all the crashes.
Since this plugin has not actually worked in any browsers for a long
time now, time to delete it.
https://bugzilla.gnome.org/show_bug.cgi?id=766776
While the new per-desktop overrides in GIO are easier to use for
both developers and users, it is still inconvenient for everyone
who changed the defaults using the old overrides hack to lose
their settings. Address this by running a small script on startup
that migrates existing settings.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
Depending on hardware and recorded volume level, turning up the speakers
to the maximum volume may not be enough and the user will want to amplify
the volume above 100%. Currently this requires opening the sound Settings
panel which gets cumbersome when required repeatedly.
To support this case better, allow raising the sound volume above 100%
directly from the system menu if the feature is enabled via the
`allow-volume-above-100-percent` key in `org.gnome.desktop.sound`.
Add a debug command (to be executed manually via Alt+F2) to check
that all of gnome-shell's file descriptors have the CLOEXEC flag set.
This is important so that internal file descriptors do not get passed
to apps when they are launched.
It prints a warning message for every fd that does not have the flag set.
fdwalk() is used from the standard library if available (it is not
available in glibc), otherwise we use the same implementation as glib
has internally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen. This check is somewhat irrelevant because we are only forking
to immediately exec(), which will discard the whole virtual address
space anyway.
This issue can be avoided by using a new optimized gspawn codepath in
the latest glib development version, which uses posix_spawn() internally.
For the optimized codepath to be used, we must not pass a child_setup
function, so the the file descriptor management is reimplemented here
using new glib API to pass fds to the child process. The old API will
continue to be used on older glib versions.
We must also change the spawn flags for this code path to be hit.
I checked that gnome-shell's open file descriptors are all CLOEXEC
so using G_SPAWN_LEAVE_DESCRIPTORS_OPEN should be safe.
This will result in more resilient app launching when memory is low,
since the optimized spawn path avoids cloning the virtual address
space of the parent process (gnome-shell) and avoids the irrelevant
memory overcommit check.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
Some systems define it to /usr/lib64 on 64-bit systems, which is not
where systemd looks for unit files. Just hardcode 'lib' in the install
prefix until we get to use the pkg-config file.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/424
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
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Package managers usually take care of compiling GSettings schemas and
updating the .desktop database on installation, but when building
manually from source, we should perform the aforementioned actions
ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/127
find_program() defaults to require the program in question, and as
failing to locate it is now fatal, there's no longer a need for
checking whether it was found later.
Spotted by Michael Catanzaro.
The previous implementation of the CSS generation logic considered sassc
an optional dependency and made sure for that reason that the result CSS
files ended up in the source directory, so that they could be checked
in and kept in sync with the source sass files.
As we are making sassc a required dependency, we can now stop doing that
extra work and simply rely on the CSS files being automatically generated
each time the sass sources change. By doing this, we can now effectively
get rid of the CSS files checked in the repo as well as of the parse_sass.sh
script, since the CSS files will now live on the build directory only.
https://bugzilla.gnome.org/show_bug.cgi?id=792822
IBus was initially made optional as gnome-shell depended on too
recent API. This API is now old enough and gnome-shell is committing
further to IBus by implementing a ClutterInputMethod through it.
Let's just make IBus a mandatory dependency, instead of making code
paths trickier to cater for situations where it's missing.
gvc has made some recent changes that rename its user options
following meson guidelines for GNOME packages[0].
The options used in gvc as a subproject have been renamed
accordingly.
[0] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
Auto-detect options add some convenience for platforms where a
particular feature isn't available - systemd on non-Linux OS comes
to mind - but the downside is that it is easy to accidentally build
without a desired feature. We consider the latter much more serious
nowadays, so turn our auto-detect options into regular boolean
options.
https://bugzilla.gnome.org/show_bug.cgi?id=791007
Meson options are typed, so the prefix isn't necessary, and indeed
looks odd when used to disable the option:
-Denable_foo=false
Also replace underscores with dashes, which is the preferred meson
style.
https://bugzilla.gnome.org/show_bug.cgi?id=791007
