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
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.
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 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.
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.
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).
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
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.
r10680 has most the dbus bits required for querying and exposing gtk menus.
rpc_types (maybe "menu-action" and "application-action"?) which just re-use the same dbus call_function code
UBUNTU_MENUPROXYbased on whether the server and / or client support the application menu feature
menu forwarding for gtk clients - still needs rpc code
Done for gtk menus in r10692.
Ubuntu, two options:
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.
Mostly done for OSX in r10705 (tiny fixups in r10706 and r10707), still TODO on osx:
More OSX updates:
patched gtkosx application file
More OSX updates:
more proper reference counting for shared dbus menu services
what this feature looks like with an osx client
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:
@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.
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.
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.
Or remove them altogether?? #2163
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/228