[Scummvm-devel] Limited keyboard input ports: New functionality for agi's predictive dialog

[Kostas Nakos]

Hello all,

The predictive input dialog of the agi engine is a great way to enjoy 
agi games in devices with limited keyboard input. It is designed to work 
optimally in devices with a phone-like numeric keypad (I'll be 
concentrating on this kind of devices for the rest of this email).

With respect to the WinCE backend though, two problems arose:

1) To bring up the dialog, the user had to click on the command line. 
This means that the cursor had to be navigated from the playfield down 
to the command line with the mouse emulation keys, then a click to be 
performed (and later back up). This deters from fluent gameplay.

2) On such limited input devices, the user is free to map a set of 
actions (including mouse emulation, left/right clicks and so on) to 
arbitrary buttons on the device. This means that the keypad buttons 
which are utilized by the predictive dialog can be - and are in practice 
- mapped to actions. Hence their keycodes are changed on the fly by the 
backend. If this issue was left as is, the user would have to navigate 
with the mouse emulation to the dialog's buttons and click them, also 
deterring from fluent gameplay. (Also note that the backend supports an 
on-screen virtual keyboard, which is as bad as the abovementioned 
situation when used for command line input).

The currently implemented solution for the issues is, respectively:

1) Addition of a Common::Event:
This enables the port to signal the display of the dialog (for WinCE, 
this can be bound to a key, like all other actions). It is accomplished 
by returning a Common::EVENT_PREDICTIVE_DIALOG in OSystem's pollEvent.

2) Addition of a new OSystem::Feature:
When the predictive dialog is shown, the new kFeatureDisableKeyFiltering 
is set to true. When the dialog is destroyed, it is set to false. This 
way, the backend can temporarily unmap the keypad keys of any action, so 
that they are fed to the dialog directly.

If you find this functionality useful, please apply it too. I strongly 
doubt that these additions will create any regression on existing code, 
even if the backend doesn't honor this event/feature.

Regards,
Kostas