On Tue, 8 Jul 2014 22:26:07 +0000 "Dodier-Lazaro, Steve" <s.dodier-lazaro...@ucl.ac.uk> wrote:
> A couple of notes on the previous emails, > > Fabrice, so long as your app ensures that no third-party code can > programmatically grab a shortcut without user agreement, it would make sense > to let it have a privilege. > > Quite obviously a compo should have the last word and be able to refuse a > request to grab a certain shortcut. If this happens, compo developers please > do provide the requesting app a displayable/translatable explanation that > your end-users would understand ;) > > I don't quite like the idea of a permission prompt from the compo for setting > up keyboard shortcuts. In the vast majority of cases the user is already > using a specific GUI for that and possibly setting up more than one shortcut > (e.g. shortcuts to newly installed media app), so it'd be awkward for them to > receive a permission prompt. I think privileges work much better here (or > User-Driven Access Control with a button that when clicked displays a > compositor-owned dialog inviting the user to select a global shortcut). > A wild thought in passing, which likely borrows from things I've heard from others before... What if applications would install config file snippets, a la configdir design, which specify a semantic action by identifier string, and the default suggested hotkey, gesture, or whatever. Or maybe they would be in the app's .desktop file, whatever The compositor would watch this directory, and when files there change, it would read them and notice that e.g. now there is a new hotkey action available. However, all that would do is light up a marker somewhere in the desktop UI saying "you have new hotkey actions available, click here to set up all your hotkeys". So the new hotkey would *not* work simply by the app's actions or by installing the app. The user can go into the hotkey config dialog in his DE UI, there see as highlighted the new things, and have the option to accept the default key binding, choose another key, or just leave the action unbound. The idea being that they are all under the DE (compositor) control, that is under the user's control, and all in one place. When the app is actually started, it will register for the semantic action by its identifier string, and then it may or may not get it triggered. No privileges needed so far as I can see. Also nothing above says it must be Wayland protocol. It could as well be dbus. And it could as well apply to X11-based DEs! Or maybe existing DEs already have a hotkey registration system, and we have to do nothing more on Wayland standardization specifically?... So it might not even be a Wayland thing at all. If a hotkey action needs to do something that is most of the time not allowed, like raise a window to the top (using a hypothetical protocol I'm not sure exists yet), I suppose the simplest thing would be for the hotkey action event to carry a "serial" like input events do, so the app can use that as a ticket to allow the "raise the window" request to be accepted. This would need integration in the Wayland protocol. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel