Hi all,<br><br>I am working on the new key mapping architecture in the course of my GSoC backends project. As I see, Max's idea (<a href="http://wiki.scummvm.org/index.php/Talk:Keymapping_Improvements">http://wiki.scummvm.org/index.php/Talk:Keymapping_Improvements
</a>) is generally approved, so I would like to post some implementation ideas to get your feedback.<br><br>First of all, we introduce new type of events called UserActions. They hold the information about the type of action (the most important property), it's human readable description for referencing in key mapping dialogs, the default key (will be used by the backend to automatically map the action if this default key is available on the device), and whether the action mapping is required or optional (bool required;). I propose that the action types are developed on a totally abstract layer, meaning that we simply have engine specific (quit, pause, save/load) and game specific actions (move left, right, jump, fight, etc.). This way we'll have a totally device independent code, we'll be able to map an action that by default is assigned to, say, a mouse click to some keyboard button. And we'll also have a nice, readable code. Though this is actually the point where I would like to get most of your comments, as these abstract action types will require a bit of work from the engine authors. Another important detail: I propose to replace the KeyCode enum with ButtonCode enum (and KeyState struct with Button struct respectfully) which will be basically the same with the only difference that it will also contain codes for mouse buttons and all other device specific buttons. This way we can map our actions directly to any buttons available.
<br><br>All of the key mapping will be handled in the event managers. Each backend will have its own event manager which will be aware of all device buttons and able to detect which button was pressed/released. Engines on the other hand will provide these event managers with all the actions it and the currently selected game needs. It will be the job of the GenericEventManager (a base class for all backend specific event managers) to resolve button/action mappings, save/load these mappings, open key mapping dialogs, etc. GenericEventManager will also provide a way to find out which button was actually pressed that generated this specific action as this may be needed by some engines (or maybe even simply to return pressed buttons, depends on the engine needs). Any other specific features may be added by the backend authors in their own implementations of GenericEventManager.
<br clear="all"><br>Please, write comments of what do you think of this, what features will be useful and what not; maybe you also have your own ideas to share.<br><br>-- <br>Best regards,<br>Serhiy Batyuk