Input/control events

[17twenty]

I've been wondering about how we should do event handling. I'm thinking we need to abstract into a separate thing from the window management and have some dude_events and an events_ queue that doesn't depend on anything else.

It could work such that events are raised and posted to a fifo and then serviced as and when, possibly with some lifetime information (or all events only live for one iteration?).

What are your ideas and thoughts?

[iamscottmoyers]

OpenCL has a similar event queue.

Since this is a single threaded application the event handling should be pretty simple. Unfortunately the window manager main loops are event handlers so we can't put our own event handling loop around it. We could call our event handler from the window manager callbacks or add a separate thread that handles the event queue (I'd rather not add another thread as it complicates things).

The new event fifo will be of benefit to us when we define our own events that aren't to do with the window system. Until then the event fifo would just be doing what we have at the moment.

Events in a fifo survive until they are serviced by the consumer. Since we only have one thread we will always have to consume all events in the fifo before returning to glut/gtk main. This may seem a bit odd e.g. "Why put the events on the queue, why not just execute the event immediately?", but if servicing an event can generate multiple events using the fifo is much easier to follow than recursion.

A simple way to integrate an event handler would be to make all window manager callbacks look something like this:

static void consume_events()
{
    while(!event_fifo.empty())
    {
        event_t *event = event_fifo.pop();
        service_event(event); /* This may add more events to the event_fifo. */
    }
}

/* Window manager calls this callback. */
static void rotate_callback()
{
    push(event_fifo, rotate_event);
    consume_events();
}