Created attachment 211135 [details] [review]
accel cell renderer: support modifier 'tapping'

Introduce a new GTK_CELL_RENDERER_ACCEL_MODE_MODIFIER_TAP that accepts
tapping modifier keys (eg: simply pressing and releasing the Windows
key) as accelerators.

I could see allowing modifiers as keys, but it doesn't make much sense to me as an accel-mode. The documentation for accel-mode says:

  Determines if the edited accelerators are GTK+ accelerators.

Which is not really what this is about, right ?

I'm somewhat worried that allowing this is highly 'anti-social', in terms of claiming large swaths of accelerator space for a single action.

The status quo is that we have two types of accels:

 1) gtk style
 2) "other" style

I added this as a 3rd option to prevent changing the semantics of the existing "other" option.  It could just be inserted there if you think that makes more sense.

I'm incline to agree with the comments about anti-social behaviour, but there are already two noteworthy cases where this happens.  The first is the windows key in the shell (and unity).  The second is how unity uses the alt key to open to the HUD.  In that case, it only performs the action in the case of a tap as described here (ie: press followed by immediate release with no other keys/mousebuttons pressed).  In that case it's not really eating up accelerator space since the other accelerators (or mnemonics) on the alt key continue to function normally.

As for the shell, I can imagine that we'd one day add accelerators based on the windows key in a similar way to what windows itself has done.  In that case I'd expect what happens now -- the overview is not activated unless the windows key is tapped (ie: press/release with nothing between).

Here is a proposal: 
- Make this a separate boolean, 'allow-bare-modifiers' or so
- Make it work for both accel-modes
- Make sure GtkKeyHash accepts bare modifiers as accels

Then you need to make sure that gsd and all the other places where system-wide accels are implemented deal properly with bare modifiers

I can accept that the user may want to assign tapped modifiers as keyboard shortcuts for random things in g-s-d, but I'm not sure I agree about Gtk...

That would then point towards accepting naked modifiers as part of OTHER ?
Since the control-center panel is already using that mode...

I looked a bit into this.  Grabbing naked modifiers in a way that doesn't break everything else is a tricky business.  You can see we already have a rather visible existing bug:

  - try to bind something g-s-d handles to Windows+X (like opening calculator)

  - notice that the key is taken, saying the key sequence is 'Super + X'

  - notice that the key sequence doesn't actually do anything

Try the same thing again with a function that's handled by the shell -- like showing the command prompt.  That works just fine.

Obviously the way the shell is handling the super key is interfering with g-s-d's ability to grab other keys.  That's an existing bug.  It would be rather unfortunate to worsen the situation by having g-s-d do the same thing with other modifiers.

Worth mentioning one bit of prior art that we have here: the 'press control to show the mouse position' thing.

That's pretty close to the behaviour we want.  Control + another key = mouse is not shown.  Tap control = mouse is shown.

Probably the method used here (labeled "Owen magic" at the site of implementation) is the way to proceed...

We could conceivably turn that into a generic keybinding with this work...

A related use case is bug 678155

Created attachment 289203 [details] [review]
accel cell renderer: support modifier 'tapping'

Ported to master

Review of attachment 289203 [details] [review]:

did you want to push this, Lars ?