Alt summoning of heads-up-display interferes with Emacs

[Barry Warsaw]

This is probably not a unity bug, because I can verify this on both unity and unity-2d desktops, but I couldn't figure out where else to file it (hmm

Previously, Alt-<key> would invoke an application's menu. Now, tapping Alt quickly will bring up the applications heads-up-display. While this occurs with any application that has global menus, this behavior is most problematic with Emacs which is a heavy user of Alt prefixed keybindings.

The problem is that when in Emacs, it's *very* common to hit and hold the Alt key while thinking about or waiting to complete the key chord. An example is Alt-n and Alt-p to move the window up or down, or Alt-i to add a tab stop, etc. Thus, my left thumb is *always* hitting the Alt key, sometimes hovering on it, other times lightly tapping it as I unconsciously decide what my next command is. Frankly, I was never aware of how often I tap Alt, as I've been doing this for probably 30 years. Now, this previously innocent tap invokes the heads-up display and *severely* impacts productivity, as subsequent typing goes to the HUD instead of to Emacs. Meaning, I lose a lot of typing until I realize what's going on and then hit escape. Because of the interaction with HUD it can actually take several seconds to figure out what's going on, and revert it.

The same thing happens to a slightly lesser extent with normal desktop Alt-Tab to switch between windows. Linger slightly longer on Alt before you hit TAB and instead of switching windows, you're now interacting with HUD.

There's got to be a better way!

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity (not installed)
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
ApportVersion: 1.94-0ubuntu1
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
Date: Mon Mar 5 15:24:29 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110228.1)
SourcePackage: unity
UpgradeStatus: Upgraded to precise on 2011-06-17 (262 days ago)

[Marc Deslauriers (mdeslaur)]

I'm getting this issue also when I use virtual machines that uncapture the mouse with Shift-Alt. It's pretty annoying to have the HUD pop up every time.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jean-Baptiste Lallement (jibel)]

I'm also working a lot with VMs for testing and this interferes with CTRL+ALT to exit the viewer or worst ALT+arrow to switch console.

As a workaround, the gconf key for the HUD key is /apps/compiz-1/plugins/unityshell/screen0/options/show_hud and you can unset it with:
gconftool -t string -s /apps/compiz-1/plugins/unityshell/screen0/options/show_hud ""

or remap it to any other key of your choice.

To restore the original mapping run:
gconftool -t string -s /apps/compiz-1/plugins/unityshell/screen0/options/show_hud "<Alt>"

[Michael Hope (michaelh1)]

You can be naughty: install ccsm, configure the Unity plugin, and disable the 'Key to show the HUD' shortcut.

[Dave Walker (davewalker)]

I used 'ccsm' to change the keybinding (Under Unity), because it was interfering with irssi.

[Barry Warsaw (barry)]

Thanks for the suggestions, but I'm not sure they work for Unity 2D (which I have to use).

E.g.

% gconftool -g /apps/compiz-1/plugins/unityshell/screen0/options/show_hud
%

and yet the HUD still gets summoned on Alt.

[Gerry Boland (gerboland)]

Hey Barry,
Unity2D doesn't use those settings, they're Unity only. The Alt key is hardcoded in unfortunately. This could be made a setting if enough people want it. I advise opening a bug asking for the Alt key to be a dconf option, and hopefully we'll get to it.
-G

[Barry Warsaw (barry)]

On Mar 05, 2012, at 11:39 PM, Gerry Boland wrote:

>Unity2D doesn't use those settings, they're Unity only. The Alt key is
>hardcoded in unfortunately. This could be made a setting if enough people
>want it. I advise opening a bug asking for the Alt key to be a dconf option,
>and hopefully we'll get to it. -G

Thanks Gerry, I filed bug 947613

I think I found the hard-coding in shelldeclarativeview.cpp so I'm #if-defing
it out and trying out a local build of the package to get my desktop usable
again.

Cheers.

[Didier Roche-Tolomelli (didrocks)]

This is fixed (and a duplicate of) bug #923410, on priority list, #1 on the list. However, releasing unity 5.6 is blocked for some days on quite few release critical bugs…

[Didier Roche-Tolomelli (didrocks)]

This is for -3d case, for unity-2d, it seems to be different (even if there are not that many false positive). I'm only targetting it to -2d now.

[Vincent Ladeuil (vila)]

@Barry: to work around modifiers being stealed ;) I've used different ones via xmodmap, so I can use EmHcs with meta, hyper and super without worrying about Alt.

That's only a short term workaround though as I really want to try the HUD:-/

[Barry Warsaw (barry)]

On Mar 06, 2012, at 12:56 PM, Vincent Ladeuil wrote:

>@Barry: to work around modifiers being stealed ;) I've used different
>ones via xmodmap, so I can use EmHcs with meta, hyper and super without
>worrying about Alt.
>
>That's only a short term workaround though as I really want to try the
>HUD:-/

Yeah, but sadly that's the antithesis of usability. ;)

Unfortunately, unity-2d with the HUD ifdefd out ftbfs in my PPA. :(

[Clint Byrum (clint-fewbar)]

"Hopefully we'll get to it"...

This has made Unity-2D almost unusable. Alt-Tab now means "switch windows and start searching there" instead of "switch windows".

This means as I type this, if I alt-tab to my terminal where my IRC client is running, and start typing, it searches the terminal's windows. Even better, if I hit alt to un-summon the HUD, I get taken back to my browser.

The only way to get reliable window switching seems to be holding down alt-tab for a bit so that you get the window picker.

alt is such a critical key for even non-power users (alt-tab is quite universal..).. how could one think that it would be ok to co-opt its usage?!

unity-2d:
  Installed: 5.6.0-0ubuntu2
  Candidate: 5.6.0-0ubuntu2
  Version table:
 *** 5.6.0-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

[Gerry Boland (gerboland)]

Hi,
of course we don't want to push something that causes standard behaviours to break. However in my and my team's testing, Alt+Tab works perfectly fine. HUD only appears for a single rapid tap of the Alt key, Alt+anything else does not show HUD.

We're unable to reproduce this behaviour, and as a result we've no idea what's wrong.

To try help us, can you run "xev" in a terminal and then
1. tap the alt key to open HUD
2. tap it again to close it
3. Try an Alt+Tab
Then attach the xev output to this bug.

Anything additional might give us a clue. You using external USB keyboard? Is it wireless? What keyboard layout are you using? and custom xmodmap's done?
Thanks in advance, we really want to fix this for everyone
-Gerry

[Barry Warsaw (barry)]

On Mar 19, 2012, at 02:46 PM, Gerry Boland wrote:

>of course we don't want to push something that causes standard behaviours to
>break. However in my and my team's testing, Alt+Tab works perfectly fine. HUD
>only appears for a single rapid tap of the Alt key, Alt+anything else does
>not show HUD.

I guess the question is what "rapid" means. In Unity 2d, I can press the Alt
key, hold it for a second or two, then release it, and it will invoke the
HUD. On Unity 3d, this (i.e. a two second hold of ALT) will not invoke the
HUD. I never realized before this how often I hover-tap ALT while
Emacsing. ;)

>We're unable to reproduce this behaviour, and as a result we've no idea
>what's wrong.
>
>To try help us, can you run "xev" in a terminal and then
>1. tap the alt key to open HUD
>2. tap it again to close it
>3. Try an Alt+Tab
>Then attach the xev output to this bug.

I can also invoke the HUD if I hit Alt-Tab *very* quickly. It could be a
timing thing. E.g. it's possible that I'm hitting Alt just slightly sooner
than TAB, and that when I do land on TAB, the HUD's already invoked. The same
movement afaict does not invoke the HUD under 3d though.

>Anything additional might give us a clue. You using external USB keyboard?
>Is it wireless? What keyboard layout are you using? and custom xmodmap's
>done? Thanks in advance, we really want to fix this for everyone -Gerry

My Unity 2d environment is a MacBook Pro, running Precise in a Fusion VM.
Standard internal keyboard, no xmodmapping going on, standard English layout.
Alt is mapped to the physical Apple command (cloverleaf) key. I'm fairly
certain this isn't hardware or even VM environment specific though, as I've
talked to several other Unity 2d users on various (more normal) configurations
and this is a very common problem.

[Michał Sawicz (saviq)]

Dnia 2012-03-19, pon o godzinie 22:29 +0000, Barry Warsaw pisze:
> I guess the question is what "rapid" means. In Unity 2d, I can press
> the Alt key, hold it for a second or two, then release it, and it will
> invoke the HUD. On Unity 3d, this (i.e. a two second hold of ALT)
> will not invoke the HUD. I never realized before this how often I
> hover-tap ALT while Emacsing. ;)

Not happening here, and since I wrote some of that code, it's explicitly
designed not to do that. If I hold alt for more than 500msec, the HUD
will not come up.

> I can also invoke the HUD if I hit Alt-Tab *very* quickly. It could
> be a timing thing. E.g. it's possible that I'm hitting Alt just
> slightly sooner than TAB, and that when I do land on TAB, the HUD's
> already invoked. The same movement afaict does not invoke the HUD
> under 3d though.

However fast I try to Alt+Tab, no HUD is coming in :/, but if I fail to
press (or release) Alt _before_ tapping Tab, then HUD indeed does come
up. But that's a missed shortcut.

> My Unity 2d environment is a MacBook Pro, running Precise in a Fusion
> VM. Standard internal keyboard, no xmodmapping going on, standard
> English layout. Alt is mapped to the physical Apple command
> (cloverleaf) key. I'm fairly certain this isn't hardware or even VM
> environment specific though, as I've talked to several other Unity 2d
> users on various (more normal) configurations and this is a very
> common problem.

I would actually be very keen to say VM is the issue. I've had that with
"keyboard integration" mode in VBox, because the initial Alt press was
sent to the VM, but then since Alt+Tab was a host shortcut, Alt was
"taken away" from the VM and it triggered the HUD. If you have others
that reported the issue, if you could please come here and report their
findings that would be great. To test otherwise you could attach a USB
keyboard and make the VM be the "owner" of that USB device to see if you
can still reproduce.

--
Michał Sawicz <email address hidden>
Canonical Services Ltd.

[Oliver Grawert (ogra)]

i see the same issue here, i often alt-tab between windows with one hand while marking and pasting with the mouse. if i release tab but keep my finger close to alt (sometimes touching it) during this process the HUD gets in my way. this behavior forces me to take away my hand from the kbd all the time and seriously slows down my work process due to that (apart from being really annoying) ...

[Barry Warsaw (barry)]

On Mar 20, 2012, at 08:40 AM, Michał Sawicz wrote:

>Dnia 2012-03-19, pon o godzinie 22:29 +0000, Barry Warsaw pisze:
>> I guess the question is what "rapid" means. In Unity 2d, I can press
>> the Alt key, hold it for a second or two, then release it, and it will
>> invoke the HUD. On Unity 3d, this (i.e. a two second hold of ALT)
>> will not invoke the HUD. I never realized before this how often I
>> hover-tap ALT while Emacsing. ;)
>
>Not happening here, and since I wrote some of that code, it's explicitly
>designed not to do that. If I hold alt for more than 500msec, the HUD
>will not come up.

I appreciate that, but I think you can see by all the other comments in this
bug that there's still something going on that's killing people's
productivity on 2d. I don't think everyone else is running in a VM, but even
if they were, it's still IMO necessary to provide *some way* to disable or
remap HUD invocation. Alt is just way way too ingrained in people's muscle
memory to not be effected by this. See Clint's comment in this bug. It
really needs to be addressed somehow or 2d will be basically unusable for a
large percentage of people.

Let me know what I can do to help debug the issue. Or, I am happy to test any
pre-release fixes for the problem.

Cheers,
-Barry

[Clint Byrum (clint-fewbar)]

Outer window is 0x4200001, inner window is 0x4200002

PropertyNotify event, serial 8, synthetic NO, window 0x4200001,
    atom 0x27 (WM_NAME), time 13657013, state PropertyNewValue

PropertyNotify event, serial 9, synthetic NO, window 0x4200001,
    atom 0x22 (WM_COMMAND), time 13657013, state PropertyNewValue

PropertyNotify event, serial 10, synthetic NO, window 0x4200001,
    atom 0x28 (WM_NORMAL_HINTS), time 13657013, state PropertyNewValue

CreateNotify event, serial 11, synthetic NO, window 0x4200001,
    parent 0x4200001, window 0x4200002, (10,10), width 50, height 50
border_width 4, override NO

PropertyNotify event, serial 14, synthetic NO, window 0x4200001,
    atom 0x10d (WM_PROTOCOLS), time 13657013, state PropertyNewValue

MapNotify event, serial 15, synthetic NO, window 0x4200001,
    event 0x4200001, window 0x4200002, override NO

ConfigureNotify event, serial 21, synthetic NO, window 0x4200001,
    event 0x4200001, window 0x4200001, (0,0), width 178, height 178,
    border_width 0, above 0x400799e, override NO

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x192 (_NET_WM_ALLOWED_ACTIONS), time 13657015, state PropertyNewValue

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x192 (_NET_WM_ALLOWED_ACTIONS), time 13657015, state PropertyNewValue

ReparentNotify event, serial 21, synthetic NO, window 0x4200001,
    event 0x4200001, window 0x4200001, parent 0xe4f9bf,
    (0,0), override NO

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x115 (_NET_WM_DESKTOP), time 13657016, state PropertyNewValue

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x115 (_NET_WM_DESKTOP), time 13657016, state PropertyNewValue

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x112 (_NET_FRAME_EXTENTS), time 13657017, state PropertyNewValue

ConfigureNotify event, serial 21, synthetic NO, window 0x4200001,
    event 0x4200001, window 0x4200001, (1,28), width 178, height 178,
    border_width 0, above 0x0, override NO

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x13a (WM_STATE), time 13657017, state PropertyNewValue

PropertyNotify event, serial 21, synthetic NO, window 0x4200001,
    atom 0x11b (_NET_WM_STATE), time 13657017, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x4200001,
    atom 0x147 (XKLAVIER_STATE), time 13657021, state PropertyNewValue

MapNotify event, serial 22, synthetic NO, window 0x4200001,
    event 0x4200001, window 0x4200001, override NO

VisibilityNotify event, serial 22, synthetic NO, window 0x4200001,
    state VisibilityUnobscured

Expose event, serial 22, synthetic NO, window 0x4200001,
    (0,0), width 178, height 10, count 3

Expose event, serial 22, synthetic NO, window 0x4200001,
    (0,10), width 10, height 58, count 2

Expose event, serial 22, synthetic NO, window 0x4200001,
    (68,10), width 110, height 58, count 1

Expose event, serial 22, synthetic NO, window 0x4200001,
    (0,68), width 178, height 110, count 0

PropertyNotify event, serial 22, synthetic NO, window 0x4200001,
    atom 0x11b (_NET_WM_STATE), time 136570...

[Michał Sawicz (saviq)]

Dnia 2012-03-20, wto o godzinie 14:59 +0000, Clint Byrum pisze:
> I think 500ms is *way* too low a threshold, and a different heuristic
> needs to be used to determine whether or not a user wants the HUD. I
> alt-tab constantly, rapidly, and the HUD comes up every time unless I
> hold down alt-tab long enough to see the window switcher, which feels
> like an eternity when it is enforced for every quick window
> switch. :-/

No no, it's not that we treat every alt press under 500ms as an alt tap.
We only treat it as one _if_ no other key was pressed (thus, any
shortcut shouldn't ever trigger the HUD). Worst thing is none of us can
reproduce your issues...

--
Michał Sawicz <email address hidden>
Canonical Services Ltd.

[Barry Warsaw (barry)]

On Mar 20, 2012, at 03:16 PM, Michał Sawicz wrote:

>No no, it's not that we treat every alt press under 500ms as an alt tap.
>We only treat it as one _if_ no other key was pressed (thus, any
>shortcut shouldn't ever trigger the HUD). Worst thing is none of us can
>reproduce your issues...

I wonder how tied this is to either MBP keyboards (native install or virtual
machine) or the switching of Alt/option and Command/cloverleaf?

I have two MBPs, one which runs Precise in a Fusion VM, and the other which
runs Precise natively. On the former, I swap those keys in OSX and that gets
exposed automatically to the VM. On the latter, I use xmodmap to swap the
keys.

I haven't tried recently, but later today, I'll log into the native MBP using
unity 2d and see if or how the behavior differs. Unity 3d on the native
install does not have this problem.

-Barry

[Clint Byrum (clint-fewbar)]

Ok, so weird data point, I tried swapping alt/win back to default, and that did not fix it. But then I logged out/back in, and the behavior went away.

I have been having odd race issues with X not working at bootup with my keyboard/trackpad... I wonder if this is part of it.

[Clint Byrum (clint-fewbar)]

just FYI, that change was not permanent... getting HUD quite often again.

Is there anything interesting in the xev output I pasted?

[Barry Warsaw (barry)]

On Mar 21, 2012, at 02:51 PM, Clint Byrum wrote:

>just FYI, that change was not permanent... getting HUD quite often again.
>
>Is there anything interesting in the xev output I pasted?

Another question. From a running, logged in system, what is the most
definitive way to tell whether you're running 2d or 3d?

I *think* I logged in with 2d on my native MBP, remapped the keys with
xmodmap, and now Alt is behaving (in the sense that it isn't driving me
nuts). But I want to be sure I'm using 2d, and I want to use that desktop a
bit more before I say for sure.

[Michał Sawicz (saviq)]

Dnia 2012-03-21, śro o godzinie 15:13 +0000, Barry Warsaw pisze:
> Another question. From a running, logged in system, what is the most
> definitive way to tell whether you're running 2d or 3d?

$ ps aux | grep unity-2d

Should do. There are some visual differences, too, like the dash not
"flowing" into launcher / panel, but just stopping there abruptly.

And, until today, the dash / launcher / panel are not colorized with
your wallpaper colour.

--
Michał Sawicz <email address hidden>
Canonical Services Ltd.

[Barry Warsaw (barry)]

On Mar 21, 2012, at 04:17 PM, Michał Sawicz wrote:

>$ ps aux | grep unity-2d

% ps aux | grep unity-2d
barry 3024 0.0 1.3 178948 26904 ? Sl 10:01 0:03 unity-2d-panel
barry 3025 0.0 2.8 416760 57520 ? Sl 10:01 0:04 unity-2d-shell
barry 4438 0.0 0.0 4368 812 pts/3 S+ 13:11 0:00 grep unity-2d

So it looks like I am running 2d on my native-boot MBP 1,1. I'll continue to
play with this machine more thoroughly and report back later.

[Barry Warsaw (barry)]

So I've been playing with unity-2d on my MBP running Precise natively. While the inadvertent HUD invocation is somewhat less annoying, it still comes up quite often when it's not wanted. Please provide a way to tune, remap, or disable this!

[Albert Astals Cid (aacid)]

For the people having the problem with the HUD being triggered incorrectly under unity-2d it would be great if you could install the unity-2d packages at my PPA
https://launchpad.net/~aacid/+archive/ppaprecise/
and do the following after upgrading
open a terminal
killall unity-2d-shell
killall unity-2d-shell (yes you need this twice)
unity-2d-shell
And then trigger the bug and write here which keypresses you did and attach the output of unity-2d-shell

The code at my PPA has extra debugging enabled that will monitors the state of the internal code that is responsible of triggering the HUD and will hopefully help us find what is wrong in the unity-2d code.

If like Barry says what happens is that you happen to tap Alt without wanting to do it and thus HUD showing is not a bug, but still you would like the HUD toggling key to be configurable, you should have a look at bug 969256