On 11/21/2014 10:30 AM, Daniel Stone wrote:
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: - 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 - for all other hotkeys (i.e. including non-modifier keys), then we take action on press - 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
That seems correct to me. The point is that this sort of action is irregardless of whether it is a "server shortcut" or not. If a client had Ctrl+Shift do something and Ctrl+Shift+X do something else, then it will trigger the first action on the release of Shift. The second action it would trigger on the press of 'X'. The logic in the compositor is identical. Nothing special is done about a key up or down until it figures out it triggered a shortcut, then that up or down event is not sent to the client.
I suppose in theory a client could have Ctrl+X and Ctrl+X+Y as shortcuts and it then treats Ctrl+X as a modifier. And this seems to have led to the concern that the server has to be able to do this, without the ability to query other programs whether there is a conflicting key combination. However I don't think there are any clients that do this, for the simple reason that it will make the Ctrl+X shortcut look broken or slow and contrary to user expectations. Since clients with a full ability to implement this do not do this, there is no reason to try to do it in this case where it is actually not possible.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
