<br><br><div class="gmail_quote">2010/12/14 Mike Paquette <span dir="ltr"><<a href="mailto:paquette.mj@gmail.com">paquette.mj@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> On Dec 13, 2010, at 4:47 PM, Daniel wrote:<br> <br> > Any thoughts on keyboard input?<br> <br> I recently completed work on a novel window system not too different from Wayland. We ran across a number of potentially desirable features and behaviors regarding keyboard input.<br> <br> * Keyboard mapping/translation<br> <br> We found it handy to have the keyboard mapping done in the server. An initial mapping table was loaded at startup, based on the user's preferred language and the type of keyboard present. At login time, the user's preferences were consulted, and an optional mapping table could be loaded that overrides the startup table. Some folks wanted the ability to use a different mapping just within their application, so we added the ability to associate a mapping just with one stream of events, to a specific application.<br> <br> </blockquote><div><br></div><div>One small question to get the hang of this. I use the awesome colemak keyboard layout (<a href="http://colemak.com/">http://colemak.com/</a>) which has a top row that reads "qwfpg" instead of "qwerty". Yesterday, I installed Starcraft 2 and was amazed to see that it recognized this and remapped its hotkeys to fit my keyboard layout automatically. For instance, the "e" (qwerty) hotkey was mapped to "f" (colemak) which it has the same physical location on the keyboard. Had it remained at "e" (colemak) I'd have to press "k" (qwerty) which, needless to say, would be much less usable.</div> <div><br></div><div>I was genuinely surprised by this, as it's the first (and only!) application that managed to recognize and adopt to my keyboard layout. Previously, I had to either setup hotkeys manually (time-consuming) or switch between colemak/qwerty when chatting/playing (annoying and error-prone).</div> <div><br></div><div>My question is, how could this be implemented using your keyboard mapping scheme?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> * Hot keys</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Hot keys, or keystroke combinations set to preform a specific system management task rather than generate key events, can be set. These hot keys are typically used to manage display brightness, sound volume/mute, or activate specialized functions such as soft disk eject, or activating a display overlay. A hot key is typically a function key, or a key in the main array of keys combined with modifier keys, such as Control-Alt-Delete. We grouped the hot keys into system-level non-overridable and non-disableable keys, user interface controls that could be disabled or overridden, and application level keys that could be disabled or overridden. There's a bunch of fiddly refinements to these that I can go into if anyone is interested. (Full screen apps disabling almost all hotkeys automatically, for example.) Hot key events are routed to specific applications registered with the hot key. </blockquote> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> We implemented a registry mechanism that handed out hot keys first come, first served, which also checked for silly things such as registering 'a' as a hot key, no modifiers, and handled collisions between hot key requests, including the system reserved keys.</blockquote> <div><br></div><div>Sounds like a refined version of X11 passive grabs. What happens when an application requests a hotkey that is already registered at UI level? (Fail or override?)</div><div><br></div><div>The fullscreen-mode-disables-hotkeys touch is great!</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> <br> * Key Thief<br> <br> This is the behavior where an application grabs the keyboard focus for a while, then hands it back. We wound up actually implementing a stack of Key Thiefs. (Why is a fascinating UI design question inappropriate for this list.) When a key thief grabs keyboard focus, the former focus holder gets an event telling him that he has lost the keyboard focus, so UI can be updated if needed. When a key thief releases focus (procedurally, or by ceasing to run) focus is returned to the prior holder with a notifying event so UI can be updated if needed.<br> <br> It may be desirable for a key thief to have the option of disabling most hot keys.<br></blockquote><div><br></div><div>Can a thief propagate the stolen events back to the receiving event queues? Is it possible to receive keyboard events without input focus? (I'm thinking of the following scenario: multi-window application that uses a dedicated input thread to coordinate input for all windows).</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> <br> * Secure Input Mode<br> <br> Secure input mode is done for security hardening. While an app is using secure input, keystrokes cannot be monitored or 'sniffed' by other applications. Key thiefs are held off. We actually propagated this state to the kernel, where additional code blocked off input monitoring facilities. The intent is to make key loggers harder to write, and more obvious when installed ("Why do I have to patch the kernel and X Server to install a flying pigs screensaver?").<br> <br> </blockquote></div>I like this very much. Very much indeed!<br>