TR : [ercp-dev] Virtual keyboard handling API proposal

[<EXT-Frederic.Philippe@xxxxxxxxx>]

________________________________

De: Leveau Franck (EXT-Atelier-MSW/France)
Date: mar. 20/12/2005 11:06
À: Philippe Frederic (EXT-Atelier/Finland); rogalski@xxxxxxxxxx
Cc: DG.Java-eSWT-Dev@xxxxxxxxx
Objet : RE : [ercp-dev] Virtual keyboard handling API proposal


Hello Mark,
 
It is ok for us to incorporate this kind of change, except that we have some comments concerning some differences between the proposed virtual keyboard event handling API and usual eSWT event handling API (but maybe these comments arrive a bit late now...).
 
First, methods of an eSWT event listener usually take the event as parameter instead of the related widget.
So it would be: int queryShowKeyboard(VirtualKeyboardEvent event)
 
Second, methods of an eSWT event listener usually return void and, if they want to override the default behavior, they set some fields in the event. So the method of the virtual keyboard listener would be:
void queryShowKeyboard(VirtualKeyboardEvent event)
and the doit field might be set to false in order to cancel the display of virtual keyboard.
 
Finally, but this is minor, instead of adding a new kind of event, a new kind of listener and the related methods in MobileDevice, already existing api could be used to be more coherent:
- public void inputChanged(MobileDeviceEvent event) is a method of MobileDeviceListener.
- event data (or is it feature?) field contains an Input object representing the input feature that has been added or removed.
- current Input types are: SOFTKEYS, KEYPAD, LIMITED_KEYBOARD and FULL_KEYBOARD. A new type, VIRTUAL_KEYBOARD, could simply be added.
Well, maybe virtual keyboard can not really be considered as an Input type and also it would be the only one that could be canceled by setting doit field in inputChanged method, so maybe introducing new event and listener would be more appropriate. We don't know what would fit best.
 
Of course, we suppose that each platform may decide to support or not this feature of allowing developper to control the display of virtual keyboard. So PDAs targetted by bug 106486 would support this feature so that the bug would be fixed and other platforms could also support this feature depending on their ability to control it through native code.
 
Finally we just want to warn that this kind of change may lead to lots of other similar change requests (that would be very device specific) for handwriting recognition, voice recognition, etc...
 
Best regards,
Franck
 

________________________________

De: Philippe Frederic (EXT-Atelier/Finland)
Date: lun. 12/19/2005 5:01
À: Leveau Franck (EXT-Atelier-MSW/France)
Objet : TR : [ercp-dev] Virtual keyboard handling API proposal


 

________________________________

De: ercp-dev-bounces@xxxxxxxxxxx de la part de ext Mark Rogalski
Date: lun. 19/12/2005 16:16
À: ercp-dev@xxxxxxxxxxx
Objet : [ercp-dev] Virtual keyboard handling API proposal



Please vote on whether to incorporate the following change into the Mobile Extensions specification:

Some mechanism is required to give applications control over the display of 
virtual keyboards when a widget gains focus. (See bug 106486). The mechanism 
granting the most control is that of a  listener which can respond yes or no 
regarding the display of the virtual keyboard whenever a widget  capable of 
text input gains focus. It seems to me that this, being a mobile device 
specific feature, is best located in the MobileDevice class. 

 MobileDevice {
  void addVirtualKeyboardListener(VirtualKeyBoardListener vkbdl);
  void removeVirtualKeyboardListener(VirtualKeyBoardListener vkbdl);
 }

 VirtualKeyBoardListener {
  /* the following method returns one of:
   VIRTUAL_KEYBOARD_SHOW
   VIRTUAL_KEYBOARD_HIDE
   VIRTUAL_KEYBOARD_DEFAULT
  */
  int queryShowKeyboard(Widget widgetGainingFocus);
 }

 Expected operation:
  If a VirtualKeyboard listener is added, then MobileDevice will monitor focus events. When a widget is gaining focus, the listener's query method is called to determine whether to display the virtual keyboard. Otherwise, a default policy is implemented.
  The default policy will examine whether a real keyboard is present or attached and cause the virtual keyboard to display accordingly.