Event management and events under the hood

Question

I just worked with some simple programs using SDL, and it made me remember some of the Java GUIs I wrote.

In simple SDL programs, I have a loop that checks for any events (keystrokes, mouse clicks, etc.) and responds to them. This is essentially a survey for input.

In Java, you connect listeners to GUI objects, and listeners start when certain events occur.

My question is, does Java just handle this poll loop in the background for us and develop things like clicking on a GUI control so that it can call the correct listener or is something more complicated going on?

I know that Qt has a similar event system for Java, where you use slots to connect a handler to a GUI control. It’s also just processing all the polls and developing, which control was clicked for us? Or again, is there something more complicated?

UPDATE

Perhaps I was not clear enough with the question. I'm really looking to find out how an event bridges the boundary of the OS level - the boundary of the application level. Does the application request the OS level and display information about the event in the application? Or the OS has some way to interrupt / notify the application that an event has occurred, and insert information about the event into the application.

I was offered a third solution that the application calls a blocking function, for example:

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

Answer 1

"... I'm just processing this polling cycle in the background for us ...?"

To a large extent, yes. The user interface system gives the program access to the queue, which contains the events that occurred, and the target. A program goes through a loop requesting elements from this queue, and then it does everything. Libraries such as Qt and Java call special functions in widget classes that tell them that an event has occurred so that the system can function from there, but this was provided by the API. To do this, the library must translate from the identifier of the system window to the class that controls these widgets.

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

Each user interface system is slightly different, but they are all basically the same in my experience. We are talking about raw win32 and xlib.

Answer 2

As previously reported by respondents, it is system-specific and can be implemented in any case.

If I remember the Windows API rights (many years ago), a “window function” appeared that was called for each event, and I made a lot of choices to choose the right action depending on the type of event.

I think most toolkits abstract this out as Java AWT with its event dispatch queue.

For protocol X, the input events (as well as “your window needs to be drawn”) come in the form of event messages via cable, and the instrumentation library can either convert it to an application function call or add them to the request queue later.

In fact, the X protocol works (mainly) with two byte streams: one from the application ("client") to the system ("server"), one in the other direction. The client sends request packets, the server sends results (for some types of requests), errors (if some request cannot be executed for any reason), and events (when something happens on the display, like a mouse movement, a key press, resizing the window, ...).

For local displays in modern systems, this is usually implemented using some shared memory mechanism, but in principle, it can go through TCP (or today mainly via SSH) for remote connections (thus, "over the cable").

Once I started creating a clean implementation of the Java X client (I didn’t complete it because I found other interesting things), and there I just used Socket with InputStream and OutputStream to connect to the server. Thus, in principle, I used the Socket-InputStream function blocking my own read() to wait for events (and results and errors). I could use java.nio.SocketChannel in non-blocking mode, too, and then basically I would have a polling cycle (by the way, by the way, of course). (Or I could use a selector, waiting for new readable data to appear - this way, blocking too.)

I have no idea what mechanism the AWT-for-X implementation used in the Java and Solaris Java implementations implements, I believe that they are based on some proprietary toolkit, which, in turn, is based on the X-client library ( for C) "Xlib", but I don’t know if there is a poll, wait blocking or someone calling in the database.

Answer 3

I am not familiar with Qt, but in Java basically, yes. In practice, it becomes more complex, with modal dialogs, etc., but basically it receives events from the base OS (for keyboard and mouse) and publishes them as events in EventQueue, and various components receive these events and use and consume them or transmit them as you wish.

The listener structure allows the component to determine what was in the event and pass the corresponding information about it to the corresponding listener.

Answer 4

This is the oldest resource, but by the way, the Java AWT / Swing queue