unity-dev team mailing list archive

[Ryan Beasley <rbeasley@xxxxxxxxxx>]

Hey Ted,

Thanks for chiming in so quickly.  :)

On 02/07/2012 08:06 PM, Ted Gould wrote:
> This one is easy because you can set the UBUNTU_APPMENU environment
> variable to NULL and that'll disable menu exporting.

D'you mean UBUNTU_MENUPROXY?  If so, we're aware of that one.  :)  (Just 
checked UBUNTU_APPMENU, and it didn't seem to have any effect.)

I can name three problems of varying severity w/ this approach:

1.  It applies only to freshly launched applications.  Anything up and 
running before the user enters VMware's Unity mode is unaffected -- the 
menus have already been proxied.

2.  UBUNTU_MENUPROXY doesn't seem to work w/ XUL applications (Firefox, 
Thunderbird).

3.  We've used this workaround for Ubuntu 2D so far, and excepting the 
caveats above, worked well while testing through Ubuntu 11.10.  I just 
tried it out w/ a 12.04 VM w/ full-on Unity 3D, and while Alt-F (for 
example) does pop up the context menu where I'd expect (occluding the 
application menu), the actual menu /bar/ isn't rendered _at all_.  It's 
neither in the application window nor in the global menu.

So, like, check this out:

I went on a crack-induced binge a few weeks ago where, by heinously 
subverting the com.canonical.AppMenu.Registrar service / 
unity-panel-service, I was able to get applications' menus to toggle 
between remaining in the apps' windows and globally proxied.  This 
didn't seem to interfere w/ the desktop session or applications, and I 
also didn't notice any long term side effects.

This made me wonder whether it'd make sense for that service to also 
have an "inhibit" API, similar to gnome-screensaver.  (By having an 
inhibit method tied to a D-Bus client, if, $deity forbid, the VMware 
Tools crash, unity-panel-service would be able to go back about its 
normal business.)  While inhibited, clients' menus would remain in 
purview of the client windows.  Once uninhibited, the service would 
resume proxying menus to the global menu bar.

I can't commit to anything atm, but if a) this was a good idea (most 
important), and b) a wild patch were to magically appear implementing it 
"soon", would Canonical consider taking it for 12.04?

> > [ Jason's notes about maximized titlebars. ]
> >
> > Third, when our users enter VMware Unity mode with an Ubuntu Unity DE
> > VM, we need to hide the left side dock/launcher bar.
>
> These are done by Compiz using the Ubuntu Unity plugin.  In theory, you
> should be able to disable and renable the Unity plugin.  Here be
> dragons, and it's not something we've really tested.  Compiz has some
> complex dependency chains that might break -- not sure.  Try it,
> reply :-)  It might work on a default installation, but if a user has
> customized their Compiz setup it'd be more fragile.  I'm guessing most
> of your users don't do that though.
>
> So, in general, it's not a case that we've actively developed for, but
> there's no reason that it shouldn't work...

Yup.  Tried this (toggling the Compiz plugin), too.  :)

Problems I ran into here are as follows:

1.  User may be using Unity 2D, in which case changing the Compiz 
settings doesn't seem to have any effect.  (There may be some common 
gconf keys between Compiz & Metacity, but none that seemed relevant to 
our case.)

2.  Disabling & enabling that plugin then pops up dialogs re: keybinding 
conflicts.  It's not pretty.  :\

Now, in the 2D case, it looks like Canonical has a custom Metacity which 
checks a gconf pref, /apps/metacity/general/show_maximized_titlebars. 
Toggling that seems to work well enough.

Still not sure about the 3D case.  I'm assuming this is up to the window 
decorator selected by Compiz, but I haven't had enough time to really 
dig into that.

So .... uhh .... got any add'l pointers?  =)

  - Ryan