Hi Max,<br><br>Taking into consideration your comments, here is a new refined proposal of key mapping implementation.<br><br><div><span class="gmail_quote">On 7/13/07, <b class="gmail_sendername">Max Horn</b> <<a href="mailto:max@quendi.de">

max@quendi.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As I stated in my last email on the subject, I am not convinced

anymore that a new event type is the way to go here, at least for in game key mapping. It requires extensive changes to all engines to work, when we could achieve virtually the same goal by generating fake key/button press events...

But a UserAction struct definitely is needed to allow engines to tell the backend what kind of "UserActions" it supports, aye.</blockquote><div> I also agree that key/button press events will save us a lot of work. That is what I actually wanted to get from you as a feedback on UserActionType enum.

<br>So, as you probably also mean it, I propose to use UserAction struct (maybe, even renaming it to ActionMapping, to better reflect its purpose) strictly for mapping purposes. How this will look like:<br><br>- I will repeat myself, but each engine/game will have a list of ActionMapping constant objects with their string descriptions and default keys;

<br>- now, the default keys will be the keys currently used in the engines/games;<br>- once the engine registers its supported actions with the event manager, the event manager will map its available inputs to these default keys;

<br>- with regard to such event as EVENT_QUIT I don't see a reason to use a

new UserActionType enum instead of already present EventType enum;<br>- in the pollEvent function, once a backend key is triggered, the backend will look and find the correct default key and/or the corresponding EnumType to set into the Event struct; (this way we don't have to modify the engines' code at all)

<br><br>By the way, as you pointed this Max, it would be nice to have default key mapping tables for all the backends.<br>And, yes, it seems that virtual keyboard should fit nicely into this idea of key mapping.<br></div>

<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> They hold the information about the type of action (the most<br>> important property), it's human readable description for

<br>> referencing in key mapping dialogs, the default key (will be used<br>> by the backend to automatically map the action if this default key<br>> is available on the device), and whether the action mapping is<br>

> required or optional (bool required;).<br><br>I don't think a "bool required" is quite enough, we'll need a more<br>fine grained "int priority", I think. There are some *crucial* maps,<br>

some "very nice to have", and some "other stuff" actions, and many in-<br>between. Yet the number of available buttons usually is small, and<br>varies between different devices, so we should be flexible in this

<br>regard.</blockquote><div><br>Yeah, sure, we can add a priority field to ActionMapping.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

BTW, another thing I just had to think off: Some "user actions" are<br>context specific and only relevant at certain times. The "keyboard<br>fighting" in Indy3 & Indy4 comes to mind. For that it would be nice

<br>to be able to dynamically & temporarily remap everything.</blockquote><div><br>We can simply use register/unregister mappings functionality to achieve that. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> I propose that the action types are developed on a totally abstract<br>> layer, meaning that we simply have engine specific (quit, pause,<br>> save/load) and game specific actions (move left, right, jump,<br>> fight, etc.).

<br><br>Not sure I fully understand you here, so let me just sketch my<br>thoughts: What I had in mind here originally was that we have some<br>generic types, i.e. those which are likely to be used by many many<br>engines; and beyond that, we simply allow the engines to use their

<br>own internal IDs. The backend would not know anything about these<br>IDs, and wouldn't *have* to know about them either; the IDs are for<br>internal referencing only, and (in the case of the "global" ones),

<br>can be used to help ensure consist mapping across games or even engines.</blockquote><div><br>Not sure I get the idea of engine and game IDs. Can you, please, describe it in more detail?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

In a nutshell: I think it's hopeless (due to the amount of work) and<br>pointless (where's the benefit) to try to come up with an enum of all<br>possible "action types". But maybe that wasn't what you had in mind

<br>anyway (it was/is not quite clear to me what precisely you meant<br>above :-).</blockquote><div><br>It was but I agree it would take too much time to develop<br></div><br></div>-- <br>Best regards,<br>Serhiy Batyuk