Created attachment 253619 [details] [review]
wayland: add support for a private gtk-shell protocol

This protocol will be used by mutter-wayland and gtk to replace
the _GTK X11 properties for DBus names/paths.

Created attachment 253620 [details] [review]
wayland: restore support for the application menu

If the compositor supports the gtk-shell interface, use it to
export the application ID, dbus name and paths that can be used
for the application menu.

Looking briefly at this, I think we need the wayland backend to update the gtk-shell-shows-app-menu setting, so we get fallback when using a Wayland compositor that doesn't support the gtk-shell interface.

I think the two are kind of orthogonal, because it's theoretical, but if Unity supported wayland, we would have a menubar and not an app menu, but it would still expose gtk-shell.

what if you run gnome apps under weston, say ? or hawaii, or a future kde/wayland ?

(In reply to comment #5)
> what if you run gnome apps under weston, say ? or hawaii, or a future
> kde/wayland ?

I would expect these would not expose gtk-shell (weston may, but the other two are unlikely), so yes, in that shell-shows-app-menu would be false.
I was just saying that the presence of gtk-shell is not enough for the setting to be true.

I think the protocol looks fine, just wondering if it should use a gnome_* prefix instead of gtk_*?  Looking at the second patch it looks like all the info comes from inside gtk, so I suppose it's fine.

You can drop the %-server-protocol.h makefile rule since this is only client side.

Anyway, the wayland side looks fine to me, I defer to Matthias on the gtk+ side of things.

( Just a process nitpick: I wouldn't split this into two patches.  The first patch introduces new unused infrastructure, which looks weird, and the next one then makes use of it.  My rule of thumb is that it's good to break commits down into logical steps (for bisecting and reivew etc) but for new code/features, I always try to land a complete piece in one commit. )

(In reply to comment #6)
> (In reply to comment #5)
> > what if you run gnome apps under weston, say ? or hawaii, or a future
> > kde/wayland ?
> 
> I would expect these would not expose gtk-shell (weston may, but the other two
> are unlikely), so yes, in that shell-shows-app-menu would be false.
> I was just saying that the presence of gtk-shell is not enough for the setting
> to be true.

But there is no api to find out if gtk-shell is present or not, and no attempt is made to update the shell-shows-app-menu setting.

Created attachment 253925 [details] [review]
gtk-shell: extend the protocol with shell capabilities

Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.

Ok, this covers gtk-shell-shows-app-menu too. If there is
no gtk_shell, we never initialize shell_capabilities, and thus
both settings are FALSE

Created attachment 253934 [details] [review]
wayland: set the wm_class on toplevel windows

Before mapping the window, set the title and class, to allow
application tracking by gnome-shell.

While we're there...

Review of attachment 253925 [details] [review]:

ok, looks reasonable.

Review of attachment 253934 [details] [review]:

sure

Review of attachment 253620 [details] [review]:

ok

Review of attachment 253619 [details] [review]:

ok

Attachment 253619 [details] pushed as d34335e - wayland: add support for a private gtk-shell protocol
Attachment 253620 [details] pushed as ed9f55d - wayland: restore support for the application menu
Attachment 253925 [details] pushed as 7f8bf41 - gtk-shell: extend the protocol with shell capabilities
Attachment 253934 [details] pushed as 3c5d9d6 - wayland: set the wm_class on toplevel windows