Hi, > I can't imagine blocking all/none shortcuts can be the only choices. > What if the nested wm does not use one of the shortcuts? And whether a > particular shortcut is used can vary: a tab between windows may not > work if you are on the last window, in that case it would be nice if > tab then went out of the nested wm and to the next main window. > > An "I consumed/ignored this event" request sent back from clients to > the compositor would allow this to work. This also matches how a > number of toolkits work so it would make integration of them into > desktops better.
I'd rather keep the protocol lean and simple. If anything, existing application do not need to know which shortcuts are used, for example, virt-viewer has no idea what particular shortcuts the desktop running on the guest OS is using. And toolkits do not know that either. > As for the X thing, I don't see why any new api is necessary. The X > emulator can just set normal Wayland keyboard focus to the window and > do whatever is necessary so that moving the focus away is discouraged > and it is easy to get the focus back (ie mouse enter and click try to > put it back), rather than add an extremely dangerous and unwanted api > from X to Wayland. It is necessary for [1] and [2], ie X11 applications that map an override redirect window and grab the keyboard. I tried the appoach you mention and was denied, on valid the grounds [3] that O-R should not be focused by the WM. While this works just fine in X11 thanks to the keyboard grab, it cannot work in Xwayland without a mechanism that route the keyboard events to the surface even when not focused. Cheers, Olivier [1] https://bugs.freedesktop.org/show_bug.cgi?id=96547 [2] https://bugzilla.gnome.org/show_bug.cgi?id=752956 [3] https://bugzilla.gnome.org/show_bug.cgi?id=752956#c4 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
