#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: |
Description
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)
Change History (20)
comment:1 Changed 8 years ago by
Priority: | major → minor |
---|
comment:2 Changed 8 years ago by
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 8 years ago by
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 7 years ago by
comment:5 Changed 5 years ago by
Milestone: | future → 0.16 |
---|---|
Priority: | minor → major |
Status: | new → assigned |
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.
comment:6 Changed 5 years ago by
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_type
s (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!)
Changed 5 years ago by
Attachment: | gtk-menu-forwarding.patch added |
---|
menu forwarding for gtk clients - still needs rpc code
comment:7 Changed 5 years ago by
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)
comment:8 Changed 5 years ago by
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.
comment:9 Changed 5 years ago by
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 5 years ago by
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..)
Changed 5 years ago by
Attachment: | gtkosxapplication_quartz.c added |
---|
patched gtkosx application file
comment:11 Changed 5 years ago by
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 5 years ago by
Attachment: | menus-refcount.patch added |
---|
more proper reference counting for shared dbus menu services
Changed 5 years ago by
Attachment: | osx-baobab-application-menu.png added |
---|
what this feature looks like with an osx client
comment:12 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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.
comment:13 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 3 years ago by
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:16 Changed 3 days ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/228
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.