Most people use their computer without knowing how they operate “under the hood”. They can spend a lifetime without caring about this subject. Programmers need to understand the mechanism to be able to create GUI programs that interact with user actions from the mouse and keyboard. Without deep understanding the GUI, programs created might be imperfect.
In this article I will explain how computer GUI works, from the mouse to the screen.
Every time we use the keyboard and the mouse, an interrupt signal is created. Interrupt signal is a logical pulse of “1” traveling in a special wire from the interrupting device to the computer. Upon receiving this signal, the CPU stops whatever it was doing at that point, and goes to a special small program to handle the interrupt. This program is called a “driver”. The driver program checks the device and read the value in it. If the device is a mouse, the values will be the pointer moved, the direction and magnitude of the movement. Or it can be button clicked, and an indication of which mouse button clicked. In case of the keyboard, the values will indicate which keyboard keys were pressed. (There might be several keys pressed like control-alt-del).
The driver pulls the values, puts them in a special queue and returns, allowing the CPU to resume its regular information.
The driver’s code is very important to the regular operation of the computer as it runs in ‘privilege’ CPU mode. Corrupted drivers can, and often do, cause the infamous “blue screen of death”.
The operating system runs a special code in its own process picking up the value presented to it by the driver. (This type of signaling is often called “software interrupts”). This special code attempts to identify the hardware signal and responds to it.
In case of a mouse movement, it attempts to identify if it is one click or double click? Is it a dragging window signal? The main activity is detecting which window the mouse cursor is over and sending the signal to that correct window. The window will draw the mouse cursor over it. (Sometimes in another shape to represent “busy” state).
In case of a keyboard signal, it checks if it is a special key that should be handled by the operating system (control-alt-del) or a regular keyboard key. Regular keys have to be sent to the active window (The window that has the “focus”). The window then can draw the letter that has been pressed on the screen (among other actions).
Every GUI program has a special code run in its own thread that handles the event.
Let’s assume we have GUI window program of a button. This program gets signals like “mouse button pressed”. This information should be handled by showing the button in its pressed position. The button should get a message that it has been pressed. The GUI program perform a routing that should take place in this event.
Since a GUI operation has performed, the button also get signal (“WM_PAINT”) to paint itself on the screen. When getting this signal, a small program routing gets called, identifying the button state, taking a bucket of paint and a brush and painting the button as it should look at this specific time (pressed or not pressed state).
This type of signaling happens in every GUI operating system. Microsoft windows uses this type of raw signaling, force the programmers to read and process every signal. Other operating systems add an abstraction layer to isolate the programmer from the “irons” and supply “onClick()” callback routines that inform the GUI program about a specific even taking place.
In this article I have explained how GUI events occur based on user actions and how it travels through the various layers of the GUI system and program. This raw GUI behavior should be understood by every programmer creating GUI program, and people who wants to understand how their computer operates.
Author: Michael Koroy