After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707129 - wayland: support application menus
wayland: support application menus
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
wayland
Depends on:
Blocks:
 
 
Reported: 2013-08-30 14:12 UTC by Giovanni Campagna
Modified: 2013-09-03 15:04 UTC
See Also:
GNOME target: 3.10
GNOME version: ---


Attachments
wayland: add support for a private gtk-shell protocol (5.82 KB, patch)
2013-08-30 14:12 UTC, Giovanni Campagna
committed Details | Review
wayland: restore support for the application menu (4.02 KB, patch)
2013-08-30 14:12 UTC, Giovanni Campagna
committed Details | Review
gtk-shell: extend the protocol with shell capabilities (4.94 KB, patch)
2013-09-03 07:57 UTC, Giovanni Campagna
committed Details | Review
wayland: set the wm_class on toplevel windows (1.42 KB, patch)
2013-09-03 09:39 UTC, Giovanni Campagna
committed Details | Review

Description Giovanni Campagna 2013-08-30 14:12:35 UTC
We need a private protocol to set the dbus information.

This is the client side of bug 707128.
Comment 1 Giovanni Campagna 2013-08-30 14:12:37 UTC
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.
Comment 2 Giovanni Campagna 2013-08-30 14:12:41 UTC
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.
Comment 3 Matthias Clasen 2013-09-01 16:46:46 UTC
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.
Comment 4 Giovanni Campagna 2013-09-01 16:54:39 UTC
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.
Comment 5 Matthias Clasen 2013-09-01 22:26:01 UTC
what if you run gnome apps under weston, say ? or hawaii, or a future kde/wayland ?
Comment 6 Giovanni Campagna 2013-09-02 09:06:42 UTC
(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.
Comment 7 Kristian Høgsberg 2013-09-02 21:03:09 UTC
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. )
Comment 8 Matthias Clasen 2013-09-03 03:07:04 UTC
(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.
Comment 9 Giovanni Campagna 2013-09-03 07:57:13 UTC
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
Comment 10 Giovanni Campagna 2013-09-03 09:39:48 UTC
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...
Comment 11 Matthias Clasen 2013-09-03 11:23:24 UTC
Review of attachment 253925 [details] [review]:

ok, looks reasonable.
Comment 12 Matthias Clasen 2013-09-03 11:23:36 UTC
Review of attachment 253934 [details] [review]:

sure
Comment 13 Matthias Clasen 2013-09-03 11:24:10 UTC
Review of attachment 253620 [details] [review]:

ok
Comment 14 Matthias Clasen 2013-09-03 11:24:26 UTC
Review of attachment 253619 [details] [review]:

ok
Comment 15 Giovanni Campagna 2013-09-03 15:04:13 UTC
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