Created attachment 251898 [details] [review]
MetaShapedTexture: don't include private headers in public ones

Private headers are not installed, so they can't be referenced
from public ones.

Created attachment 251899 [details] [review]
build: make wayland support unconditional

In the wayland branch of mutter, we want to build a wayland version
of the mutter libraries, and that's much easier if we just build
wayland support unconditionally.
The define is kept to avoid a huge diff, but should be removed
in a later patch.
Also, wayland support can still be disable at runtime, by
launching mutter without the --nested switch.

Created attachment 251900 [details] [review]
Remove HAVE_WAYLAND ifdefs

Wayland support is always enabled now.

Created attachment 251901 [details] [review]
Remove files no one cares about anymore

mutter-plugins.pc has been replaced by libmutter.pc, and the
wm properties in the control center are long gone.

Created attachment 251902 [details] [review]
wayland: make parallel installable with regular mutter

Modify all visible instances of mutter with mutter-wayland
(libraries, folders, pkgconfig, etc.), so that the wayland
branch can be installed alongside the usual X11 mutter.

Created attachment 251903 [details] [review]
Remove the jhbuild wrapper script

It's mostly equivalent to "jhbuild run gnome-shell", which is
the preferred way. Also, running from the source tree can't be
supported at this point, and the wrapper is getting in the way
of having two binaries, one for wayland and one for X11.

Created attachment 251904 [details] [review]
Implementing building two separate binaries for x11 and wayland

Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland

Review of attachment 251898 [details] [review]:

looks fine to me

Review of attachment 251899 [details] [review]:

Will this make the eventual merging harder ? I guess that depends which way we'll go in the end. Anyway, looks fine for the branch

Review of attachment 251899 [details] [review]:

Will this make the eventual merging harder ? I guess that depends which way we'll go in the end. Anyway, looks fine for the branch

Review of attachment 251900 [details] [review]:

same caveat as before - may make the merge harder. But sure, looks fine for the branch

Review of attachment 251901 [details] [review]:

sure

Review of attachment 251902 [details] [review]:

::: configure.ac
@@ +39,3 @@
 AC_SUBST(ACLOCAL_AMFLAGS, "\${ACLOCAL_FLAGS}")
 
+GETTEXT_PACKAGE=mutter-wayland

This will have the unfortunate side-effect of making translators translate the same stuff twice. Not sure we can do much else, though.

::: src/Makefile.am
@@ +227,3 @@
 	$(libmutterinclude_extra_headers)
 
+bin_PROGRAMS=mutter-wayland

Do we actually need this binary anymore

::: src/wayland/meta-wayland-stage.c
@@ -137,3 @@
 
-  filename = g_build_filename (MUTTER_DATADIR,
-                               "mutter/cursors/left_ptr.png",

Do we actually install this file ? I don't see /usr/share/mutter/cursors on my system...

Review of attachment 251903 [details] [review]:

this is a gnome-shell patch. Looks ok to me though

Review of attachment 251903 [details] [review]:

.

(In reply to comment #13)
> Review of attachment 251902 [details] [review]:
> 
> ::: src/Makefile.am
> @@ +227,3 @@
>      $(libmutterinclude_extra_headers)
> 
> +bin_PROGRAMS=mutter-wayland
> 
> Do we actually need this binary anymore

It's useful to test stuff nested, which is good when hacking on the lower level parts of mutter.

> ::: src/wayland/meta-wayland-stage.c
> @@ -137,3 @@
> 
> -  filename = g_build_filename (MUTTER_DATADIR,
> -                               "mutter/cursors/left_ptr.png",
> 
> Do we actually install this file ? I don't see /usr/share/mutter/cursors on my
> system...

It's only there in the wayland branch.

Review of attachment 251904 [details] [review]:

The commit message should also mention that libgnome-shell-menu is broken out.

::: js/ui/main.js
@@ +102,3 @@
+    if (!Meta.is_wayland_compositor)
+        Meta.is_wayland_compositor = function () { return false; };
+

I don't know enough js to know what this does. How will Meta.is_wayland_compositor ever be defined when we get here ? Is this something that mutter exports ? If so, why do you need to replace it with a function ?

::: src/main.c
@@ +389,3 @@
   ctx = meta_get_option_context ();
   g_option_context_add_main_entries (ctx, gnome_shell_options, GETTEXT_PACKAGE);
+  g_option_context_add_group (ctx, g_irepository_get_option_group ());

Is this needed for Shell_0_1_gir_PROGRAM ? This should probably be mentioned in the commit message.

(In reply to comment #10)
> Review of attachment 251899 [details] [review]:
> 
> Will this make the eventual merging harder ? I guess that depends which way
> we'll go in the end. Anyway, looks fine for the branch

I think that if we merge, it will be after we decide to go with wayland by default for gnome in general, at which point having a compile dependency on it should not be a problem.

Created attachment 252262 [details] [review]
Implementing building two separate binaries for x11 and wayland

Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.

libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API

(In reply to comment #17)
> Review of attachment 251904 [details] [review]:
> 
> The commit message should also mention that libgnome-shell-menu is broken out.
> 
> ::: js/ui/main.js
> @@ +102,3 @@
> +    if (!Meta.is_wayland_compositor)
> +        Meta.is_wayland_compositor = function () { return false; };
> +
> 
> I don't know enough js to know what this does. How will
> Meta.is_wayland_compositor ever be defined when we get here ? Is this something
> that mutter exports ? If so, why do you need to replace it with a function ?

If we're in the wayland branch, meta_is_wayland_compositor() is part of the mutter API, and thus accessing Meta.is_wayland_compositor gives the JS wrapper around the C function.
On master, OTOH, the mutter API does not include wayland simbol, so Meta.is_wayland_compositor is undefined. To be able to call it unconditionally, we replace with a JS function that returns false, so that we then follow the non-wayland paths (like we would do with the wayland branch run as an x11 compositor)

Review of attachment 251903 [details] [review]:

.

Review of attachment 252262 [details] [review]:

Ah, ok. That makes sense

The last patch has a problem: I'm getting symbolc conflicts caused by gtk_action_muxer_get_type (in libgnome-shell-menu.a).

The same does not happen on the x11 version though...

Created attachment 252622 [details] [review]
Implementing building two separate binaries for x11 and wayland

Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.

libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API

I forgot to attach the new patch, the symbol conflicts were caused
by the different lookup rules between -export-dynamic on the process
binary and internal binding of the static library, and were solved
by making libgnome-shell-menu shared again.

Review of attachment 252622 [details] [review]:

looks good to me

Review of attachment 251902 [details] [review]:

my questions were answered in a later comment, so

Attachment 251898 [details] pushed as 1617323 - MetaShapedTexture: don't include private headers in public ones
Attachment 251899 [details] pushed as 91cdfab - build: make wayland support unconditional
Attachment 251900 [details] pushed as bd3d5df - Remove HAVE_WAYLAND ifdefs
Attachment 251901 [details] pushed as 542a088 - Remove files no one cares about anymore
Attachment 251902 [details] pushed as ea3d2b4 - wayland: make parallel installable with regular mutter

Attachment 251903 [details] pushed as 254efdd - Remove the jhbuild wrapper script
Attachment 252622 [details] pushed as 21a8583 - Implementing building two separate binaries for x11 and wayland