GNOME Bugzilla – Bug 500881
F1 Shortcut Configuration Not Configurable
Last modified: 2009-05-14 05:24:54 UTC
Change the "Launch Help Browser" shortcut in Preference->Shortcuts menu to Disabled. Restart gdm. Yelp still responds to F1. Workaround: sudo mv /usr/bin/yelp /usr/bin/yelp1 sudo echo "echo 1" > /usr/bin/yelp sudo chmod 755 /usr/bin/yelp
Still seeing this issue with default Ubuntu 8.04 + GNOME 2.22.1
Confirm on Ubuntu 8.10. Disabled Help in shortcuts and F1 still brings up the help. Infuriating.
I agree that this is an extremely annoying bug. Would love to see it fixed.
This is due each individual application having the F1 accelerator for Help->Contents. It's not a Yelp bug. It's tantamount to asking Yelp to change other applications' File->New accelerator to something other than Ctrl+N.
If this is so, why is it that I cannot override it with a window manager binding for F1? In other words, if I attempt to bind F1 to a window action using "Keyboard shortcuts", this is ignored, and the F1 is instead handled by the application (which may in turn call Yelp). Maybe the bug lies with metacity rather than Yelp, but there is still a bug here.
Moreover, Yelp still gets called when the focus is not with any application at all, and, as per the original report, the help browser is disabled within metacity. I guess this also suggests it is a metacity bug.
If it's not set as a desktop shortcut, then Metacity has absolutely no reason to catch F1, so it passes it through to the application. Honestly, there's no magic here. F1 is being treated exactly like any other shortcut. As for "when the focus is not with any application at all", how exactly do you accomplish that? If you have no windows open, the desktop has focus. The desktop is Nautilus. It can't be done in Yelp, and it can't be done in Metacity. If you want a workaround that doesn't involve moving binaries around, you could probably define F1 as a desktop-wide custom shortcut to /bin/true.
Seems I misread comment #5. You say you can't bind F1 to something else to prevent it from going through to the application? I just bound F1 to "maximize" and it worked exactly as expected. It doesn't work for you?
I thought it was this issue, but I now see I was wrong. Apologies. In fact, I was attempting to bind F1 to the "raise/lower" action, and the fact that this particular action doesn't work "out of the box" was causing the problem. The real problem is bug https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/216550 If I make the raise/lower action bindable (by turning off compiz, as suggested in 216550's thread), then I can bind F1 after all, without needing to mess with moving yelp out of the way. Thanks for your patience!