Send ApplicationMenu data from server to client

[Norman Rasmussen]

OS: Ubuntu Precise with Unity desktop

Applications launched under xpra (eg: gedit), don't display any menu, and the global menu is empty.

Workaround: export UBUNTU_MENUPROXY= before running programs, to display menu within the app's window - not global though.

It would be nice to be able to proxy the menu back to the client, so that the menu is displayed correctly in the global menu bar.

Will probably require proxying a bunch of dbus calls back and forth,
re: ​https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu

[Antoine Martin]

Meh, once again this is a huge amount of work for very little benefit, I only hope the API is not as bad as the previous appindicator horror from Ubuntu (see #43).
Best link I've found so far: ​How to add support for the global menu to a python non-gtk, non-qt app? - all pointing to the toolkits, which we don't want to use since we want to act as the menu server, not a menu client..

The biggest obstacle: if we proxy the menu stuff, the client has to be able to handle it - and unless it is also an Ubuntu client sufficiently recent, it won't (unless we then write our own menu window for those clients - yuk). So we end up with applications that cannot be used unless one uses a specific recent version of Ubuntu with specific desktop settings - yuk!.
r2364 sets the UBUNTU_MENUPROXY="" environment variable. I may backport this, and add info in the FAQ.

Ultimately, I think this Ubuntu stuff is fundamentally broken if it enables global menus even when the window manager is not aware/cooperating. At the very least, it should check for a root window property to ensure that the global menus will work, and default to OFF unless the window manager sets it.

[Norman Rasmussen]

Yea, to do it 100% correctly there may have to be client side menu's - How does OS X present menu's? Are they shown in-window like X does? It would actually be nicer to be able to show them natively at the top.

I found two resources that have some information: The general ubuntu interface project called ​Ayatana, which has some design docs and debugging information (where I found the link in the descrption). There's a project called ​Arkose that has a dbus proxy as part of it.

Unfortunately the options range from simplest (disable appmenus), to brittle/os-dependant (dbus proxy that tweaks xwinid's), to full implementation (server and client have to completely re-implement menu's)

I've no illusions, this isn't an easy thing to fix, but it's nice to have it on the potential future roadmap.

[Antoine Martin]

OSX shows the application menu in the common location in the top bar, that's what Ubuntu tried to copy (amongst other things). So in this case, OSX *could* be made to work with the Ubuntu global menus. But that still leaves all the others - what to do with them? They may not have a top bar (I don't), or even no bars at all, so this would look extremely messy.

As for Ayatana/Arkose, as far as I can tell this is a dbus proxy, which is not what we want: we want to select dbus protocols individually and emulate the client/server whilst passing the messages to the other end (or not when none are connected). Which means custom code at each end for each and every dbus signal (and more).

[Antoine Martin]

MS Windows does have a place we could potentially use for this: the customizable taskbar, see #508.

See also (more Ubuntu specific workarounds needed): #472

For gnome3: #476

[Antoine Martin]

Probably makes sense to raise this so we can deal with #476 and #489.

In the case of GTK, we may need to be able to add our own menu(s) to the forwarded ones since the systray is unusable with gnome3.

r10679 improves on r10666 and allows us to extract all the menu and actions information into python data structures, then re-inject that at the other end.

[Antoine Martin]

r10680 has most the dbus bits required for querying and exposing gtk menus.

Still TODO:

• deal with the tedious partial update API: we probably don't want to send this over the wire (far too specific to this gtk api), and just send the whole menu again instead then diff it instead (much easier and generic)
• manage paths: add a prefix to all application-ids and paths? (so we don't conflict with the same application running locally) and deal with multiple instances: maybe this prefix has to be dynamic? (using the client pid or whatever)
• add a new client capability for the application-grouping, another one for application menu?
• probably add a new packet for adding (and removing?) application-groups (or whatever we decide to call it), updating their menus?
• hooking up the new properties into the window model metadata, watching for changes, etc
• look into overriding the group-leader code?
• add command line options to enable / disable?
• forward "Activate" actions to the server via the rpc code using a new rpc_types (maybe "menu-action" and "application-action"?) which just re-use the same dbus call_function code
• makes sense to dynamically generate the environment when we start new commands, so that we can toggle UBUNTU_MENUPROXY based on whether the server and / or client support the application menu feature
• if we don't have client-side support for "global menus" (ie: LXDE or KDE), then what do we do? disable the feature? create a window as anchor for the menu? (yuk!)

[Antoine Martin]

menu forwarding for gtk clients - still needs rpc code

[Antoine Martin]

Done for gtk menus in r10692.

Still TODO:

• ubuntu's ​ApplicationMenu (aka "menuproxy" stuff) - which is very poorly documented from a developer's perspective - but their dbusmenu-dumper code may help, if I can find the source for it (​libdbusmenu-tools?)
• move the start / start-child code into the server so we can enable / disable the ubuntu menu proxy stuff (assuming we get it to work first..)
• add our own tray entries to this menu? or maybe a single entry with a sub-menu? maybe only if there is no systray available (as is the case with gnome3 - belongs in #476)
• osx (no ticket exists for this platform): the problem here is that the menu api is difficult to work with: hardcoded default entries, must re-use the same instance, does not support disabled items? etc.. - and the big one: it is a shared instance for all windows, so we would need to trigger the menu changes ourselves when the focus goes to a different window!
• win32: see #508 (not possible without a huge amount of effort)

[Antoine Martin]

Ubuntu, two options:

• wrap libdbus-menu with cython so we can use it with GTK2.. (not useful for implementing the "client" end)
• figure out this undocumented mess, looking at ​mock-json-app.c the magic happens in ​dbusmenu-server-new and then we add ​DbusmenuMenuitems to it using ​dbusmenu-server-set-root

The menu service might be easier to proxy for as the dbus interface seems relatively simple?

FWIW: dbusmenu-dumper doesn't work on Ubuntu 15.04. Yay.

[Antoine Martin]

Mostly done for OSX in r10705 (tiny fixups in r10706 and r10707), still TODO on osx:

• "Quit" entries are a bit confusing... can we rename the main "Quit" menu item to "Disconnect" somehow? (most apps have their own "Quit" menu item which does actually quit..)
• some of the "Xpra Options" menu entries don't work or don't show their submenus ("Info" is missing, etc) - the name of this menu could be improved too..
• windows don't always get the "focus-in-event" so we fail to setup the right menu - we should add a more generic hook linked to the "focus" packet (which is more reliable)

[Antoine Martin]

More OSX updates:

• the submenus are fixed by #991
• missing "Info" submenu fixed in r10712
• to change the label of the "Quit" menu item, we will need to ​edit that string in gtkosxapplication_quartz.c.. (or maybe cleaner to add some code to lookup an env var and fallback to quit? or something..)

[Antoine Martin]

patched gtkosx application file

[Antoine Martin]

More OSX updates:

• "Quit" menu item: see patched file above
• r10715: we now merge all our menus into the main menu using submenus, which frees up the space for the application forwarded menu - can be toggled back to using separate menus using XPRA_OSX_SINGLE_MENU=0 env var

[Antoine Martin]

more proper reference counting for shared dbus menu services

[Antoine Martin]

what this feature looks like with an osx client

[Antoine Martin]

This will do for this release: we do send the application menu data to the client - which matches this ticket's summary.
It is only actually used client-side on OSX...

Will follow up in:

• #476 gnome3
• #472 ubuntu
• #1035 fallback for other OS

@afarr: this is mostly a FYI. You can test by running an application like baobab (and most GTK3 applications from gnome) and you should see this application's menu integrate into the OSX global menu (you may have to unfocus the window then focus it again to get the global menu to update on OSX... which is a bit focus-challenged):

Minor edit: r11245 strips the "on HOSTNAME" part from the menu bar entry.

[alas]

Poked at this a little with the osx menu (and noticed the Disconnect Xpra in the menu, in place of quit... nicely managed).

Not sure if there's much else worth testing here, so I'll close, and search it out if I see issues in the future.

[Antoine Martin]

And now they're abandoning it: ​GNOME Plans to Move App Menus Back Inside App Windows.
Worse still, all the menus will hang off the small "hamburger" button, how intuitive, not.

[Antoine Martin]

Or remove them altogether?? #2163

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/228