Bug 217044

/apps/metacity/general/enable_windows_keys in gconf lets you turn it off, but yeah, we need something better

Hmm, this is not good name for this key ("windows_keys_show_menu" would be better) and metacity properties is not the right place, where one expects this switch.

I searched it in these two places:
- Context menu of the menu applet.
- Keybinding properties: I see there Alt+F1 (which also works) and nothing about LWin, which looks really confusing.

Technical note: Allowing more keys for the same function in the keybinding properties can be a good idea and can be used in future for enhancing support for remote controller and multimedia keyboard. (Such keybindings are supported for example by Xine using keybinding aliases.)

*** Bug 221633 has been marked as a duplicate of this bug. ***

It seems to confuse all users without MS-Windows practice. These users expect to be able to bind anything to this key.

This is not major, but its something that should be fixed in upstream gnome.  The way the menu binding works in the panel is awful.  The only thing we could do for 10.2 is change the default setting, but then we get the opposite complaint.

i'm not convinced we'd get the opposite complaint. the audience for 10.2 is very different from the audience for sled10

so you are saying that alt + f2 will not work in 10.2?

Olaf, your bug is actually slightly different from this one; the patch isn't supposed to affect the Alt key at all, only the Super/Windows/Penguin key. Are you using xmodmap or xkb to change the modifier keys around on your keyboard? Or do you have some unusual model of keyboard?

It affects the Alt_L config, appearently the config tool doesnt go after symbols but hard keycode numbers. Thats not nice.
This is a macintosh keymap. 

https://bugs.freedesktop.org/show_bug.cgi?id=8660#c11

I've been fighting with this for two weeks, until I found the work-around listed here.  I don't have a problem with the default MS Windows-style behaviour, however, it should be configured in the Keyboard Shortcuts panel, so that it can be changed there instead of having to go into the Configuration Editor.

Also, it looks like by default, Super_L is mapped to mod4, so pressing the windows  key by itself doesn't have any effect until you clear mod4 with xmodmap.

*** Bug 221723 has been marked as a duplicate of this bug. ***

JP, could you please reconsider to fix this for 10.2?  There is no way to assign shortcuts for <$windows-key> - <some-other-key>.

When disabling the windows key with the gconf key mentioned in comment #1, it can't be used for other actions such as special characters configured with Xmodmap. This makes GNOME unusaable for people having a US keyboard but need to type those special characters from their native language. Raising severity again.

Created attachment 111038 [details]
Allow Super_L to post main menu without losing function as Mod4
to apply:
1.)untar fresh metacity-2.16.3.tar.bz2 
2.)cd metacity-2.16.3
3.)patch -p0 < <path to patch file>

This patch that permits Super_L to be used both ways. It is simply a modification of the patch currently included in metacity-2.16.3-24.src.rpm. It has been tested only with the 104-key layout family.

There is no need for an either/or choice. Both user groups can be satisfied because both behaviors are possible with identical configuration. We can use Super_L for a one-touch main menu, as well as a modifier. To have our cake and eat it too, metacity must wait for a KeyPress-Super_L followed by a KeyRelease-Super_L to post the main menu. If any other event is interspersed between the press and release, Super_L can be interpreted as a modifier (usually Mod4?). Case in point is the Mod4+L, Mod4+D, Mod4+R, etcetera series expected by users from Windows.

*** Bug 230788 has been marked as a duplicate of this bug. ***

*** Bug 226074 has been marked as a duplicate of this bug. ***

Mark, can you move this to an upstream bug.

OK, it's on my TODO list.  Preferred method of indicating such: the should_go_upstream keyword.

I'm not sure entirely how I should spin this upstream.  The following possibilities exist, based on suggestions made in this bug:

- enable_windows_keys should be renamed
- enable_windows_keys (by whatever name) shouldn't be under /apps/metacity
- expose the key in the GUI through the context menu of the various menu applets
- expose the key in the GUI through gnome-keybinding-properties
- expose the key in the GUI through gnome-keyboard-properties
- upstream the patch from #14 (though it should perhaps be noted that we're evidently not using this patch ourselves).  

Of course, these options aren't mutually exclusive, but several of them have appeared since the initial suggestion that this bug go upstream (in Comment #5).

I'm starting the story of the attached patch and its antecedent in medias res, and I'm trying to catch up as best I can.  The patch  mentioned/modified in Comment #14 (metacity-windows-key-binding.patch unless I'm mistaken) was presumably the one noted in the metacity changelog entry on June 15, with reference to bug #155437 which has a comment that suggests that this functionality was in an *earlier* patch which got dropped but which doesn't seem to appear in the package changelog.  Perhaps it was an earlier Ximian patch?  It would be good to know whether the current patch has been offered upstream, especially since our current patch seems to add the enable_windows_keys key which is the main focus of the first 11 comments to this bug.  
The 50 hits for enable_windows_keys from Google seem to be SUSE-specific.

I'd like a little feedback from JP on what exactly we want to send upstream, especially since this seems to be a problem specific to a patch of ours.  Has anyone considered the modified patch from Comment #14?

FWIW, upstream is considering the larger issue of Super handling in http://bugzilla.gnome.org/show_bug.cgi?id=165343 Note that this bug doesn't specifically address any of the behavior of enable_windows_keys.  I suspect it's more relevant to Comment #12 and Comment #13 (though it may also be addressed by our patch).  

JP: if you expect to be satisfied with the ultimate resolution of this upstream bug, and you don't think our current patch requires any modification, go ahead and resolve this bug LATER, but having looked this over, I'm not going to make that call on my own.

Meant to NEEDINFO JP

This is not an upstream bug, this is something we patch ourselves explicitly.  What we probably want to do is turn it off in openSUSE by default for 10.3

Why not leave gconf_key enable_windows_keys enabled, and incorporate the comment #14 patch to avoid conflicts? What are the disadvantages/downsides?

*** Bug 251024 has been marked as a duplicate of this bug. ***

Why cannot be done everything by xmodmap?
There could be any default - I would use my own xmodmap-file...

Have a look at 
http://bugzilla.gnome.org/show_bug.cgi?id=413017
too.

Created attachment 122634 [details]
metacity for SUSE 10.2 i386 with bug-fix

Comment #26 attachment implements #14 patch. I have been using this rpm since I upgraded to SUSE 10.2. (In reply to comment #25)

(In reply to comment #25)
> Why cannot be done everything by xmodmap?
> There could be any default - I would use my own xmodmap-file...
Can we, using xmodmap, configure X to bind KeyRelease events? ...and cancel any such binding if another key is pressed between KeyPress and KeyRelease. 

In other words, can the same Xmodmap configure the (Win/Super_L) key to bring up gnome-main-menu, while also functioning as a modifier? (Mod4+ usually). If so, I would sure like a copy of your .Xmodmap!

> This is not an upstream bug, this is something we patch ourselves explicitly. 
Additionaly, the current patch, and the update in comment #14, are not candidates for upstream because they hard-code Super_L for extended functionality, and metacity maintainers have already rejected hard-coded keybindings for this issue. 
See http://bugzilla.gnome.org/show_bug.cgi?id=150897

(In reply to comment #28)
> In other words, can the same Xmodmap configure the (Win/Super_L) key to bring
> up gnome-main-menu, while also functioning as a modifier? (Mod4+ usually).

Maybe not - I just don't like, that the right win key always opens the (gnome-)main-menu ("computer") which ignores my xmodmap (containig the line:.
! keycode 116 = Super_R Multi_key
keycode 116 = ISO_Level3_Shift
)

Also if I had only one (left) win key (as I have on my notebook) I would prefer to work the win key as level3-chooser and to work as open_menu only together with shift...

What I find to be strange is (gnome2.16.1 (opensuse10.2))

open control-center:
there is
(Hardware) - Keyboard - (Belegungseinstellungen) - Alt/Win key behavior
- default
- Add the standard behavior to Menu key
- ...
- ...

[I think, it's here, where there should be a checkbox "do nothing else, than configured by xmodmap".]

And there is

(Hardware) - Keyboard - (Belegungseinstellungen) - Third level choosers

Here  i can choose:

- Press right Win key to choose 3rd level

But still the right Win key works as Main-Menu("Computer")-Starter/Opener

It seems, in this configuring dialogs Alt/Win key behavior and Third level choosers do conflict. Don't they?

(In reply to comment #31)
> - Add the standard behavior to Menu key
> - ...
> It seems, in this configuring dialogs Alt/Win key behavior and Third level
> choosers do conflict. Don't they?
They certainly did for for me. I think the gconf key /apps/metacity/general/enable_windows_keys is a great idea, it was just implemented 95%. In 10.2, it conflicts with the user's choice of modifier, third level chooser, etc. Hence, this whole discussion.

The comment #14 patch and the comment #26 rpm corrected this problem for me, allowing the behavior described in comments #14 and #15. I invite you to try the patch, or the rpm, and see if your Win key is usable as 3rd level chooser, even while /apps/metacity/general/enable_windows_keys is true.

using the patch-rpm, the win key really don't open menu by press but by press release. 

But it seems, win key is binded to compose now (?)

xmodmap 
keycode 116 = ISO_Level3_Shift
still doesn't work.

Also when I run gconf-editor and turn /apps/metacity/general/enable_windows_keys off the winkey still opens the gnome-menu and does not work as specified in xmodmap.

*** Bug 265705 has been marked as a duplicate of this bug. ***

to comment #34:

When I run gconf-editor not as root, but as user, it takes affect for me and only when I disable /apps/metacity/general/enable_windows_keys that way, the line 
keycode 116 = ISO_Level3_Shift
in my Xmodmap-file takes effect.

(But gconf makes no difference between left and right winkey.)

We could do this optionally with %sles_version.

Michael can you do this for 10.3?

Done.

(In reply to comment #37 from JP Rosevear)
> We could do this optionally with %sles_version.

That's how I did it.  For future SLES releases, there's no change.

Test packages here: http://primates.ximian.com/~maw/builds/20070913/

Changing to component GNOME. Sorry for the spam.