User:Timdream/InputMethod API with hardware keyboard: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Remove the content)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Proposed API addition w/ hardware keyboard ==
This proposal has been updated. Please refer to [[WebAPI/InputMethod_API_with_hardware_keyboard]].


''This is not planned in Firefox OS v1.2.'' See [https://bugzilla.mozilla.org/show_bug.cgi?id=??? Bug ????].
[https://wiki.mozilla.org/index.php?title=User:Timdream/InputMethod_API_with_hardware_keyboard&action=history History of this page]
 
=== Idea ===
 
The previous iteration of IM API (See [[WebAPI/KeboardIME]]) enables the keyboard apps to interact with the targeted input field. We would like it to handle the connected hardware keyboard as well.
 
The API is designed to be compatible with previous iteration: if the hardware key is not <code>block()</code>'ed, Gecko would simply do it's usual things (sending the keydown/keypress/keyup events). If the keyboard app decide to <code>block()</code> the key, it would be responsible to come up with appropriate interaction, and do the desired mutation to the input field (if it decide to further swallow the original key events with <code>unblock(true);</code>.
 
'''Why not use <code>evt.perventDefault()</code>?''' The default action of an event is evaluated as soon as all event listeners are executed. The keyboard app might not be able to decide whether or not to suppress the usual key events at that point (if the decision is based on, say, an IndexedDB async query). So we opt to <code>block()</code> and <code>unblock(handled)</code>.
 
* kanru
** Q: What about <code>interface HardwareKeyboardEvent : KeyboardEvent</code> so you don't have to copy the attributes?
** Q: What should unblock(false) do? Send the queued events to content? Could it queue more than one key events?
 
=== API addition ===
 
partial interface InputMethod {
  /*
    * Indicate the presence of a external/hardware keyboard. In response, the virtual keyboard app, for example,
    * could remove the virtual keyboard part of it's UI and only show the suggestions/candidates UI.
    * [Tim] Need a better abstracted name like "external input source" or something...
    */
  readonly boolean hardwarekeyboard;
  /*
    * Fires when the above attribute changes.
    * [Tim] Need a better abstracted name like "external input source" or something...
    */
  attribute EventHandler onhardwarekeyboard;
}
 
partial interface InputContext {
  /*
    * The "hardwarekey" event will be dispatched when the user press a key.
    * See HardwareKeyEventDetail for what could the keyboard app do to this key event in it's "evt.datail"
    * [Tim] Need a better abstracted name like "external key event" or something...
    */
    attribute EventHandler onhardwarekey;
};
 
/*
  * The interface here is inspired by mozbrowsershowmodalprompt event.
  */
interface HardwareKeyEventDetail {
  /*
    * These values are simply copied from KeyboardEvent so keyboard app gets to decide whether or not to handle the key.
    * See https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
    */
  readonly number keyCode;
  readonly number charCode;
  readonly DOMString key;
  readonly DOMString char;
  readonly boolean shiftKey;
  readonly boolean metaKey;
  readonly boolean ctrlKey;
  readonly boolean altKey;
  /*
    * Block this hardware key event and all the key events follows.
    * The key event should be unblock()'d as soon as the keyboard app has handled it.
    */
  void block();
  /*
    * Unblock this hardware key.
    * If "handled" is set to true, the usual key* events will not be sent.
    */
  void unblock(boolean handled);
}

Latest revision as of 03:33, 26 December 2014

This proposal has been updated. Please refer to WebAPI/InputMethod_API_with_hardware_keyboard.

History of this page

Retrieved from "https://wiki.mozilla.org/index.php?title=User:Timdream/InputMethod_API_with_hardware_keyboard&oldid=1044024"