Polling for SDL events in a custom QObject-derived C++ class?

[katanaswordfish]

I'm in the process of writing a QML/QtQuick application, and my goal is to be able to control this app with a variety of input devices; including some that don't seem to be officially supported by Qt like gamepad/joystick input.

It seems that the best way to go about this might be to create a new QObject-derived class in C++ that wraps "SDL's Event System":http://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlevent.html, independently checking for gamepad/joystick events and emitting signals to be used by my other QObject/QML instances.

I'm pretty new to Qt/QML still, so I'm not sure of the right way to go about this though. Every frame/update I need my QObject class to call SDL_PollEvent() in a loop (in order to retrieve each event from the internal event queue). After I poll events, I need to process the event to determine what type of event it was. After that, my plan is to emit a Qt signal specific to the event that was just processed (for example: onJoyPadLeft() signal or onJoyPadButton5() signal).

I think I could probably make a new thread that constantly polls/processes SDL events. However, I don't want to do that if there is a better way that's built into QObjects. Is there some kind of QObject function that's called each frame/update that I can use/overwrite for the sake of polling/processing SDL events? Or should I make a new thread that runs its own event-handling loop?

[pritamghanghas]

If the API that you are using for polling events is blocking, then a thread is the only option. Otherwise you can install a even filter at either the QApplication or your top level widget and do you work whenever a paint event comes.

In case of QML, I dont remember the exact details but scenegraph renders emit frame start and frameend signals. A simple search on google should give you the exact api.

Just be aware if the poll method will take a long time thread approach will be better