add timeout parameter while waiting for events

#31 Declined
  1. metagriffin

this pull request implements the feature request in issue #202.

this PR adds a timeout parameter to the wait() functions. note that libsdl only added support for SDL_WaitEventTimeout in 1.3, but the standard version in the wild is still 1.2.15, so for that reason this PR includes a backported version thereof.

another unfortunate discovery is that libsdl's implementation of SDL_WaitEvent is actually a polling wait (with a 10ms sleep)! i added that to the documentation, just so that people are aware of that ugliness...

Comments (3)

  1. René Dudfield

    Thanks! I think this sounds good. But then I stopped to think about it a bit... What is the use case here? Usually I either wait, or use event polling, or even a combination of both to wait for any event, and then get what there is. I'm sure there is one, but I can't think of it.

    What platforms have you tested this on? If someone can report back on some testing of this on a few platforms then we can consider this for 1.9.2. Otherwise we will have to wait till later.

  2. metagriffin author

    i can think of many use cases.

    most often, this is used in contexts that have a "semi-static" display, i.e. there is no moving items, but some items can update without user action. for example, if the current time is displayed: it would be horrible design to need to move to a event polling just so you can update the time every minute. much better would be to, in the main loop, calculate how long until the next minute-change event, then wait for user events with a timeout. if the timeout occurs first, update the time, and repeat.

    another example is if you have a dialogue awaiting user input, but it defaults to something after N seconds.

    i have tested this on ubuntu 12.04, ubuntu 14.04, and raspbian 2014-01-09.

  3. René Dudfield

    Ok, that does sound good! I guess similar functionality could be done by using a separate thread to post an event, but this seems much cleaner.

    We still need some more testing though. Of both existing apps, to make sure they don't break, and on other platforms. Especially windows and mac.

    • test on windows
    • test on osx
    • test on existing fastevents using apps