[Scummvm-devel] Simplifying keyboard repeat

[Max Horn]

Am 25.09.2006 um 07:32 schrieb Torbjörn Andersson:

> Max Horn wrote:
>
>>> So, the natural way to handle this is to use the native keyboard
>>> repeat when available, and to emulate it otherwise. To this end, we
>>> could either add a kFeatureKeyboardRepeat flag. Or, we could
>>> *require* backends to implement/emulate keyboard repeat, but
>>> provide the code required for that. Maybe it would even be possible
>>> to add the code require for that directly into OSystem, thus
>>> letting porters implement this with a minimal amount of work.
>
> So what you're saying is that a backend could either implement  
> repeating
> by native methods - e.g. calling SDL_EnableKeyRepeat() in the SDL
> backend - or there would be code in OSystem to automagically generate
> "fake" keyboard events as a fallback?
>
> I.e. there would be a pollEvent() in OSystem that would only check for
> "fake" events. The individual backends would still define pollEvent 
> () to
> call the original one, before doing their own stuff. On key down/up
> events, they could optionally call functions i OSystem to set up/ 
> cancel
> the generation of "fake" keyboard repeat events.

I'd rather do it with a "wrapper", so that client code doesn't have  
to be adjusted at all, I think (unless you can think of drawbacks),  
kind of like Marcus suggested.

Or, in a small deviation to this, introduce an (abstract)  
EventManager class with a pollEvent() method; add a getEventManager()  
method to OSystem. ; and then let all client code invoke the  
EventManager::pollEvent() method, which in turn would call the  
(protected?) OSystem::pollEvent, and do it's magic. Well, if  
necessary. There'd be a kKeyboardRepeatFeature. Use hasFeature to  
check whether it is supported, and then enable it, else, emulate  
keyboard repeat.

Well, EventManager could also sport a enable/disableKeyRepeat method,  
of course.

All the above holds for the DefaultEventManager, of course. By using  
OSystem::getEventManager(), we allow backends to insert custom event  
managers. The SDL backend, for example, could easily be changed by  
moving it's whole pollEvent() code into SDLEventManager::pollEvent.

This would be a step into the direction of more modularized backends.  
I consider adding getTimerManager(), getPluginProvider() and maybe  
getAudioMixer() to OSystem, too.

Bye,
Max