On 09/30/2012 01:35 AM, Pekka Paalanen wrote:
On Wed, 26 Sep 2012 08:21:44 +0200
Daniel <[email protected]> wrote:
El dt 25 de 09 de 2012 a les 11:15 -0400, en/na Kristian Høgsberg va
escriure:
On Mon, Sep 24, 2012 at 04:53:20PM -0700, Bill Spitzak wrote:
Keystrokes should be sent to the application first. Only if the
application refuses them should they be considered global shortcuts.
No.
Could you elaborate a little bit the logic leading to this decission,
please?
It is a roundtrip, which is already bad in itself.
All the normal keystorkes that a client handles are a roundtrip, so I
really can't see this being a problem. I certainly agree with Wayland's
design that once a client decides to change it's display, that it be
able to do that with no further roundtrips. But that is different than
event handling.
Furthermore, it
allows clients override global shortcuts of the compositor, which
means that it would be impossible to have secure shortcuts, e.g.
"kill this client" or "switch sessions".
There certainly would still be "secure shortcuts" like you describe.
These are identifiable to the user as "you hold down lots of strange
shift keys". For instance ctrl+alt+del. The reason "lots of strange
shift keys" are needed is to avoid breaking applications by blocking a
keystroke the application designer thought was available. My main
concern is that we don't have to make *ALL* shortcuts "lots of strange
shift keys".
The type of shortcuts I think me and Daniel are worrying about is the
volume buttons. I would like hitting the volume button to change the
volume in the current app that has focus, and only change the global
volume if that app does not have a local control.
Third, if the client
hangs, it would mean global shortcuts would stop working, and you
could not e.g. alt-tab away from a frozen window, which might be
even fullscreen.
There would be a timeout, same as being suggested for the window drag
controls, after which the shell acts as though the client ignored the
keystroke.
It would also mean, that every application would need additional
code to cooperate with the compositor. Missing that code would by
default stop all global shortcuts from working. Programmers would
have to spend effort to not break the *whole* desktop, instead of
just having their app working right with the desktop by no effort.
This just requires toolkits to require a "I used the key" return value
from keystroke handlers. The amount of work for a programmer to support
that is trivial (they are likely calling several functions that already
return this information), and failure of the programmer to do this will
result in obvious bad behavior of the application (such as breaking Tab
navigation) even if there are no global shortcuts.
You might invent elaborate schemes to overcome the latter cons,
but even the roundtrip argument alone is a serious one, and there
would have to be a serious benefit in doing so. This would just
bring a lot more problems than it would solve.
I'm worried that a "shortcut registry" will add enormous complexity and
bugs and make it difficult for programmers to get the behavior they want.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
