Events and event handling under the hood

Question

I've just been working through some simple programs using SDL and it made me think back to some Java GUIs I've written.

In the simple SDL programs, I have a loop that checks for any events (keypresses, mouse clicks etc...) and reacts to them. Essentially it's polling for input.

In Java, you attach listeners to the GUI objects and the listeners get triggered when certain events occur.

My question is, does Java just handle this polling loop in the background for us and work out things like which GUI control was clicked so that it can trigger the correct listener, or is there something more complex going on?

I know Qt has a similar event system to Java where you use slots to connect a handler to a GUI control. Is this also just handling all the polling and working out which control was clicked for us? Or again, is there something more complex going on?

UPDATE

Maybe I wasn't clear enough with the question. I'm really looking to find out how an event bridges the OS Layer - Application layer boundary. Does the application poll the OS layer and pull event information into the application? Or does the OS have some way to interrupt/notify the application that an event has occurred and push the event info to the application.

A third solution has been suggested to me that the application calls a blocking native function like:

Event e = someNativeFunction(); // blocks until someNativeFunction() returns an event

Answer 1

"...does Java just handle this polling loop in the background for us...?"

Pretty much, yes. The UI system provides the program with access to a queue that contains events that have occurred and the target. The program runs through a loop requesting items from this queue and then does whatever. Libraries like Qt and Java call special functions within the widget classes that tell them an event has happened so that the system can function from there, however stipulated by the API. The library has to translate from the system specific window ID to the class governing that widget in order to do so.

Qt provides access to this function in the form of protected, virtual onXxxxEvent() functions. The standard behavior of many widgets is to generate signals in response to events, but these are always some translated form of the event specific to the particular widget. Qt provides you access to this so that you can override the way a widget handles an event or to add additional behavior for events it never listened to before (through subclassing).

Each UI system is slightly different but they are all basically the same in this manner in my experience. We're talking raw win32 and Xlib here.