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)

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)