<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2014 08:31, Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">2014-11-20 10:05 GMT+02:00 Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>>:<br>> On 19 November 2014 21:05, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>>> No! Users do NOT want this. Keys take action when you push them. Otherwise<br>
>> the interface looks slow and drives users crazy.<br>
><br>
><br>
> That sometimes conflicts with the goal of having ambiguous hotkeys. For<br>
> instance, if you press and release Mod on its own, you'll get Exposay mode;<br>
> Mod is, however, also used as the prefix for a million other hotkeys. So in<br>
> that case, we have to arm the shortcut when mod is pressed, disarm/release<br>
> it if any other keys were pressed, and then trigger on release.<br>
><br>
> Another classic example is Ctrl+Shift used to drive layout change (this is<br>
> the Windows default), when you still want Ctrl+Shift shortcuts.<br>
><br>
> I'd hope that this was restricted to modifiers, so we could just say as a<br>
> general rule that the compositor will drive modifier-only hotkeys (Exposay,<br>
> layout switch) on release, but all others on press. So if you have ambiguous<br>
> hotkey combinations which involve non-modifier keys, well, you lose.<br></div></div></blockquote><div><br></div><div>[the above is salient]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>> In any case, DO NOT DO THIS!!!! What the above sequence should do is a<br>
>> screenshot, followed by the action of Mod+s+x in the client. This is what<br>
>> users expect and what every toolkit in the world does on every platform.<br>
>> There is nothing special about "compositor shortcuts" and they should NEVER<br>
>> act differently than a client would that handles both shortcuts. Here is<br>
>> correct behavior:<br>><br>
> I agree 100%. Again, think of nesting compositors: why should our compositor<br>
> behave completely different if it's nested? The more difficult we make it to<br>
> sensibly nest compositors, the more we're shooting ourselves in the foot.<br>
<br>
</div></div>Ok, now you got me confused. Wasn't this what you said would be the<br>
correct way to handle bindings?<br></blockquote><div><br></div><div>Sorry, was kind of mixing theoretical and practical a little bit here.</div><div><br></div><div>The only case where you need action-on-release rather than on press, is where you have ambiguous/overlapping hotkeys. For instance, Ctrl+Shift switches keyboard layouts, Ctrl+Shift+Q closes Chrome. When you have these kind of overlaps, you need to wait until release to disambiguate.</div><div><br></div><div>As in the first quoted section, I think it's not really reasonable to guard against the possibility of Mod+S taking a screenshot in the compositor, but the client having a shortcut for Mod+S+X. So I think we can take the easy way out of saying:</div><div>  - for any hotkeys which are _solely_ combinations of modifiers and _not_ non-modifier keys (e.g. Exposay as it is today), then we only take action on release</div><div>  - for all other hotkeys (i.e. including non-modifier keys), then we take action on press</div><div>  - if a client has a hotkey combination which conflicts with the above (e.g. the Mod+S vs. Mod+S+X case), then that's their problem, because it's a stupid hotkey combination anyway</div><div><br></div><div>Does that help?</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>