1,554
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
→Generic infrastructure tasks: -- add virtual keyboard and keymapper task
(Return back CinE task. Add CruisE task) |
(→Generic infrastructure tasks: -- add virtual keyboard and keymapper task) |
||
| Line 86: | Line 86: | ||
But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing). | But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing). | ||
=== Virtual Keyboard and Keymapper === | |||
''Technical Contact'': [[User:Sev|Eugene Sandulenko]] | |||
''Background:'' | |||
Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends fature virtual keyboards in different incompayible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough. | |||
''The Task:'' | |||
Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible. | |||
For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions. | |||
The keymapper should have 2 main sources of control infromation. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task. | |||
== Audio related tasks == | == Audio related tasks == | ||