I have seen you proposal for a signal-slot system and I have one remark to make: I'ld like to see the "event" that triggered the signal being given as parameter to the signal handler (slot) function. It allows one handler for all key up and down events on an object. (Do you want separate a-up, b-up, a-down, b-down functions?) --MathFox 13:33, 4 July 2009 (UTC)

The problem with that is that the method used as a slot must then take an event object whenever it is called, even outside of the event system. For example, a void move_up(); or void attack_target(); method could easily be used by bot, npc or scripting code (for example, implementing one action as several others in sequence), whereas void move_up(SDL_EventType&); or void attack_target(SDL_EventType&); could not. There may be cases where you do want to pass a value, like what tile you're over when you click a mouse button, but translating the event object into mouse position should be handled before passing it to the triggered action. That said, it would make sense to store parameter info for each slot and event, so that only events which supply the appropriate information can be used with a particular action. Also, I really do want separate slots for each action (and separate signals for each event)... --LlubNek 22:06, 5 July 2009 (UTC)

Having typed signals and typed slots is something that can easily be done in C++ (using templates to avoid source code duplication). The C++ compiler by itself will be very good in preventing you from attaching non-sense slots to signals. (Note: you want the slots to take const& parameters!) Can you detail your plans so that it becomes clearer what the effects of your proposal are for client programmers and players? --MathFox 23:15, 5 July 2009 (UTC)

I plan to use this, signal/slot library, to create a new input system.

A list of controls will be generated by enumerating the keyboards, mouses and game controllers attached to the system (at least when compiled with SDL 1.3). There would also be virtual devices (for example, to combine keyboard input from several keyboards). Each control will have a text string associated with it, constructed from the name of the device, followed by the name of the specific control (such as "Logitech, Inc. Dual Action Gamepad 0: button 0"). There will also be a set of events associated with each control, which would also be named ("Logitech, Inc. Dual Action Gamepad 0: button 0: pressed", "Logitech, Inc. Dual Action Gamepad 0: button 0: released"). These are the names which would appear in an Advanced or Edit Binding window.

A list of slots will also be generated. Each slot will be given a name, the specific class instance to call it on, and, if necessary, a bit mask indicating what parameters it requires. This should all be registered with the input system when the instance is constructed.

Once the devices are enumerated and the actions registered, the current bindings will be loaded from a configuration file. The configuration file would consist of a list of entries, each containing an event name and modifier mask and the associated action name.

Signals will be constructed when specific controls and modifiers are bound and added to a `std::map`. The keys to this map will be a `std::pair` containing a mask of the modifiers and the event which triggers the signal. When an SDL event fires, a pair is constructed as above and is checked against the map. If there is a key which matches that pair, the associated signal is emitted.

Key points: multiple controls per action, multiple actions per control, virtual devices allow input from sources other than keyboard, mouse and joystick (an automated test suite for example), adding new input devices is fairly simple, adding new actions requires no changes to the input system, and, aside from registering slots with the input system at startup, the rest of the code can pretty much forget the input system exists. --LlubNek 23:28, 6 July 2009 (UTC)

Your functional proposal is interesting; though I think it is too early to select a specific library, it might be that your library lacks some specific support that you need. Please detail the functional aspects of your proposal on your user page.

Some issues remain unclear though. Does a joystick give one signal (with a direction parameter) or four different signals (one for each direction?) (or five, adding "neutral" for stop?) If you pick a movement slot with a parameter, how do I feed key presses in it?

And a last, nasty one: Is it possible to disable so much of the input bindings that it is impossible to recover? No mouse, no clicking "enable mouse", stuck! :-/ --MathFox 21:55, 7 July 2009 (UTC)

Following up, not all handlers make sense in every situation... So you'ld have to be careful in what you present to the user (keep type information with the signals and slots.) --MathFox 13:42, 4 July 2009 (UTC)