The Common Widgets user interface has been modeled based on the input event processing model supported by OSF/Motif. A central event processing loop reads events from the operating system and dispatches them to individual widgets that process them appropriately. This event model, called polling, is the basis of most modern graphical user interfaces (GUIs) including OSF/Motif, Microsoft Windows, IBM OS/2 Presentation Manager, and the Apple Macintosh operating system.

In Common Widgets, the event polling loop has been implemented fully within high-level Smalltalk code. This has a number of significant benefits to the application programmer:

With Common Widgets, only the single Smalltalk user interface process is permitted to dispatch events or directly perform user interface operations. Common Widgets facilitates a proactive approach to event management, as opposed to a defensive one. Rather than write code to defend themselves against asynchronous user interface events, such as exposes, menu operations, or user input, application developers control the user interface event processing. Event processing is fully synchronous from the perspective of the user interface process, although it can be asynchronous from the perspective of non-UI processes.

Unfortunately, with increased capability comes increased responsibility. In the case of the polled event model, application programmers are responsible for writing their applications in ways that allow polling to occur at frequent intervals. The responsiveness of an application (that is, the delay between the availability of an event and processing of the event by the application) is directly effected by the frequency at which the application polls. Although they vary in their sensitivity to failures, all of the GUIs mentioned above specify that frequent polling is required to maintain application responsiveness.

Common Widgets provides support for maintaining application responsiveness while long-running tasks execute. This support is based on the Common Process Model together with a standard application program interface (API) for managing the interactions between non-UI tasks and the user interface. This is discussed in detail in the following sections. First, a system view is presented, which provides an overview of the implementation of these mechanisms, and then an application view is presented, which discusses how the mechanisms are used in building applications.