Fallback menus shown for windows on the blacklist

[Matthew Paul Thomas]

If a window has no menus of its own and is not on the blacklist, the fallback "File" and "Edit" window menus should be shown in the panel.

If a window *is* on the blacklist (e.g. a Firefox window), no window menus should be shown in the panel at all. Currently they're showing the fallback menus too, resulting in duelling File and Edit menus.

[Hernando Torque (htorque)]

FWIW, the same happens when running not blacklisted applications with sudo. Also, running just 'openoffice.org' will show the desktop menu instead of the fallback menu.

[Omer Akram (om26er)]

>the same happens when running not blacklisted applications with sudo.

bug 592842

[Hernando Torque (htorque)]

I'm already subscribed to that one. :-P

Just added this here, so we won't get a fix for blacklisted apps only.

[Ted Gould (ted)]

Okay, so sudo is a different problem that this bug isn't about. I beleive there's already a wishlist bug on it. This is for applications that have menus, that aren't exported into the panel so there isn't a stub menu for them.

To that aim, there is two ways the proposed branch works. One is that it has a list of desktop files that are automatically removed. It's a short list of apps that are a PITA to upload or fix easily. Two, it will work with the desktop files of any app. If that app as the key in its desktop file "X-Ayatana-Appmenu-Show-Stubs=False" then the stubs will not be shown.

[Hernando Torque (htorque)]

The sudo bug 592842 mentioned by Omer Akram actually is about "sudo apps not working with appmenu" - ok, but if they aren't working right now, shouldn't they be handled like blacklisted applications? Right now they show the same behavior as blacklisted ones (= this bug).

[Ted Gould (ted)]

No, sudo apps are unlikely to work. And in general, they should go away. If someone found a way to patch them or something I'd probably accept the patch, but I think time would be better spent migrating them away from sudo to a proper PolicyKit backend-frontend separation. I'm personally for removing sudo from main.

[Mark Shuttleworth (sabdfl)]

Why are sudo apps unsupportable? That's separate from whether sudo is a
good idea - it's here for a while, till the full migration /
architecture for separation is widely in use.

Mark

[Ted Gould (ted)]

Added in libdbusmenu-qt as I've been able to replicate this using Mumble and the preferences dialog. It's likely to be the same cause. The libdbusmenu-qt getting blocked doing the preferences action and not sending back the response. Then indicator-appmenu believes that the program has died and retries.

[Ted Gould (ted)]

@Mark, the difficulty with sudo applications is that they don't have access to the session bus of the user. I've looked at trying to give them the path (as a hack) but it still wasn't able to connect. With enough work, I'm sure it could be made to work together. But, considering how many GUI apps need to be run with sudo, I don't think it's worth the effort. The only one I know of is wireshark, and even that isn't required, just easier.

[Omer Akram (om26er)]

I think chromium-browser should also be blacklisted.

[David Barth (dbarth)]

Right, on the sudo apps, there is a separate bug tracking the issue: https://bugs.launchpad.net/indicator-appmenu/+bug/592842. sudo apps are bound to a distinct dbus session. By contrast, they access the same X display, but get permission for that because sudo is mediating the auth exchange. We haven't found a way to properly re-route dbusmenus published on another session bus to the bus that the panel indicator is listening on.

[David Barth (dbarth)]

The blacklist mechanism has been implemented and released.
The list of blacklisted apps needs to be reviewed: tracked on a separate bug task for ayatana-design.

[David Barth (dbarth)]

Adding an ayatana-design task to review the list of applications to blacklist, ie for which the menu stubs should not be used.

[Mark Shuttleworth (sabdfl)]

OK, sudo isn't a blocker for me for Maverick. Thanks for the
clarifications. Bet we could solve the problem!

Mark

[Matthew Paul Thomas (mpt)]

The list of blacklisted applications should be Firefox, Thunderbird, any other XUL applications in Main or Universe, and OpenOffice.org. That is, all applications for which we plan to recognize their toolkit's menus in future but do not yet. Once we do recognize XUL and VCL menus, the blacklist can be retired.

The blacklist should not include Chromium or Chrome, because (a) they currently have no menu bar at all, (b) "File" > "Close" usefully works right now and the "Edit" items could too, and (c) we want them to start using a full set of menus (as they do on Mac OS X), and their developers shouldn't be roadblocked when they try.

For applications that use other toolkits, such as Blender and FontForge, it should be their responsibility to integrate the menus themselves, just as it was for Mozilla and OpenOffice.org developers on the Mac for example.

[Martin Pitt (pitti)]

This is slightly confusing. This bug is still (mostly) open, but it seems that current Maverick is already behaving that way. Just now Ken VanDine proposed yet another package to hide the menu, and it seems we have to play a lot of catch-up with a lot of little dialogs which don't have menus, but cause these weird "File/Edit" menus to appear. Up to a few days ago, even the empty desktop had those menus (not sure whether those got removed by now). Also, there's probably a lot of third-party apps which we don't even know about yet, so having a blacklist sounds like a battle which we can't win.

Could we perhaps switch to a whitelist to cover the two or three apps where this extra menu actually makes sense? Or disable it for Maverick, until we get a better approach?

[Aurélien Gâteau (agateau)]

blacklist is implemented by indicator-appmenu, not by libdbusmenu-$toolkit