<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-html" lang="x-unicode"> On 20/12/13 17:24,
      Quentin Glidic wrote:<br>
      <div class="moz-cite-prefix">
        <blockquote type="cite">The first important point is here: the
          client only binds an <b class="moz-txt-star"><span
              class="moz-txt-tag">*</span>action<span
              class="moz-txt-tag">*</span></b>. <br>
          The action is a describing string and does not leak the key
          which is <br>
          bound. There would be a set of standard actions, some vendors
          ones, and <br>
          user custom ones (which application would have to support too
          with a <br>
          custom setting). </blockquote>
        I really like this idea. KDE applications already do this by
        default, all keyboard shortcuts are collected and configured in
        one place. I do hope that applications will have some way to
        suggest default keybindings (which the compositor is free to
        ignore) so the user won't have to open their system settings and
        configure everything manually for every new application that
        he/she installs (it's also hard to write tutorials for
        applications if every user has different keybindings, and
        annoying for people that sometimes use other user accounts than
        their own). The paranoid user is still free to configure his/her
        compositor to ignore all default keybindings or maybe pop up a
        confirmation dialog before accepting them.<br>
        <br>
        <blockquote type="cite">The second point: which key(s)/mouse
          button(s) to bind? <br>
          This is the compositor’s job to choose that (hey, based on the
          user <br>
          settings of course). It can have a GUI, a key file, whatever.
          I think we <br>
          should allow the same binding to have multiple actions (see
          the fourth <br>
          point). </blockquote>
        And vice versa: one action can have multiple bindings (e.g. a
        mouse gesture and a keyboard shortcut). We shouldn't limit it to
        just keyboard and mouse, the compositor should be free to use
        any mechanism it wants, such as gestures, joystick buttons,
        maybe even voice commands.<br>
        <br>
      </div>
      <blockquote cite="mid:52B46F25.3090907@sardemff7.net" type="cite">I
        think this really specific use case *must not* be mixed with
        global bindings. We should probably have a global binding
        mechanism opened to every application and a specific trusted one
        for WhatPulse and friends. <br>
        It could even be a system-wide LD_PRELOAD-like (*-like*, e.g. a
        specific hooking mechanism in wayland-server) thing that hooks
        in the wayland-server component and shipped with WhatPulse
        directly. <br>
      </blockquote>
      I agree. The two are completely different use cases and different
      behaviour is expected.<br>
      <br>
      The crucial difference is that a global binding will 'eat' the
      mouse/keyboard event, i.e. the event will not go to the current
      application. If a user decides that the T key will be his
      push-to-talk key, then they probably don't want the application to
      see that keypress (this is actually a problem with Mumble right
      now). A global binding is also not a security risk (like a
      keylogger) because it would be obvious to the user that the
      keyboard isn't working (assuming untrusted programs can't generate
      artificial keypresses). In that sense it is no more dangerous than
      focus stealing.<br>
      <br>
      On the other hand a global mouse/keyboard listener is essentially
      an invisible keylogger and this functionality should only be given
      to trusted clients.<br>
      <br>
      I think in the long term Wayland will need both, just like X11 has
      both: the former is XGrabKey (which has a lot of problems and
      limitations that I hope Wayland will solve), and the latter is the
      XTest extension. The first one is probably more important though,
      so let's focus on that first.<br>
      <br>
      Maarten Baert<br>
    </div>
  </body>
</html>