With the introduction of MetaContext, the responsibility for handling
signals was changed to the application (e.g. GNOME Shell) using
libmutter. What wasn't fixed was making the stand-alone mutter do the
equivalent as well. This commit fixes this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2007>
It'll be part of and owned by MetaContext, intending to replace
`meta_is_wayland_compositor()`, but place it in a new file for public
enums so that it can be used from wherever.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This is the filename convention you get when you define a shared module
in meson, and since there is no particular reason to not include the
"lib" prefix, lets make it easier to port it over. While at it,
de-duplicate the retrieval of the plugin name.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Conflicts:
src/compositor/compositor.c
src/meta/util.h
gnome-shell shouldn't announce to the session manager it's
"ready" until it's fully initialized. It currently tells
the session manager it's ready as soon as it hits the main
loop. This causes nautilus in classic mode to start before
we have workspaces initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
The "multiple plugins loaded at once" strategy was always a big fiction:
while it may be viable if you're super careful, it's fragile and requires
a bit of infrastructure that we would be better off without.
Note that for simplicity, we're keeping the MetaPluginManager, but it only
manages one plugin. A possible future cleanup would be to remove it entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
Move all of the mutter code into a new libmutter-wm.so, split its
main() method into meta_get_option_context(), meta_init() and
meta_run(), add methods for using in-process plugins, and add
libmutter-wm.pc pointing to the new library.
The mutter binary is now just a tiny program that links against
libmutter-wm. The --version and --mutter-plugins options are handled
at the mutter level, not in libmutter-wm, and a few strange unused
command-line options (--no-force-fullscreen and --no-tab-popup) have
been removed.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
