xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 9 years ago

Closed 6 years ago

Last modified 16 months ago

#228 closed enhancement (fixed)

Send ApplicationMenu data from server to client

Reported by: Norman Rasmussen Owned by: alas
Priority: major Milestone: 0.16
Component: core Version: trunk
Keywords: ubuntu applicationmenu dbus app-menu Cc:


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

Attachments (4)

gtk-menu-forwarding.patch (25.9 KB) - added by Antoine Martin 7 years ago.
menu forwarding for gtk clients - still needs rpc code
gtkosxapplication_quartz.c (38.5 KB) - added by Antoine Martin 7 years ago.
patched gtkosx application file
menus-refcount.patch (17.7 KB) - added by Antoine Martin 7 years ago.
more proper reference counting for shared dbus menu services
osx-baobab-application-menu.png (61.6 KB) - added by Antoine Martin 7 years ago.
what this feature looks like with an osx client

Download all attachments as: .zip

Change History (20)

comment:1 Changed 9 years ago by Antoine Martin

Priority: majorminor

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.

Last edited 9 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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).

comment:4 Changed 8 years ago by 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

Last edited 8 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 7 years ago by Antoine Martin

Milestone: future0.16
Priority: minormajor
Status: newassigned

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.

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 7 years ago by 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!)
Last edited 7 years ago by Antoine Martin (previous) (diff)

Changed 7 years ago by Antoine Martin

Attachment: gtk-menu-forwarding.patch added

menu forwarding for gtk clients - still needs rpc code

comment:7 Changed 7 years ago by 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)
Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 7 years ago by Antoine Martin

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.

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:9 Changed 7 years ago by 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)

comment:10 Changed 7 years ago by Antoine Martin

More OSX updates:

Changed 7 years ago by Antoine Martin

Attachment: gtkosxapplication_quartz.c added

patched gtkosx application file

comment:11 Changed 7 years ago by 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

Changed 7 years ago by Antoine Martin

Attachment: menus-refcount.patch added

more proper reference counting for shared dbus menu services

Changed 7 years ago by Antoine Martin

what this feature looks like with an osx client

comment:12 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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):
what this feature looks like with an osx client

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

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:13 Changed 6 years ago by alas

Resolution: fixed
Status: newclosed

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.

comment:14 Changed 4 years ago by 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.

comment:15 Changed 3 years ago by Antoine Martin

Or remove them altogether?? #2163

comment:16 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.