Widgets that are provided by a toolkit typically adhere to a unified design specification, including aesthetics, to lend a sense of overall cohesion among various parts of the application and between various applications within the GUI.
Widget toolkits also contain software to assist in the creation of window managers, as windows themselves are considered widgets. Some widgets support interaction with the user, for example labels, buttons, and check boxes. Others act as containers that group the widgets added to them, for example windows, panels, and tabs.
The graphical user interface of a program is commonly constructed in a cascading manner, with widgets being added directly to on top of existing widgets. In many implementations application windows are added directly to the desktop by the window manager, and can be stacked layered on top of each other through various means. Each window is associated with a particular application which controls the widgets added to its canvas, which can be watched and modified by their associated applications.
Most widget toolkits use event-driven programming as a model for interaction. The toolkit handles user events, for example when the user clicks on a button. When an event is detected, it is passed on to the application where it is dealt with. The design of those toolkits has been criticized for promoting an oversimplified model of event-action, leading programmers to create error-prone, difficult to extend and excessively complex application code.Finite State Machines and Hierarchical State Machines have been proposed as high-level models to represent the interactive state changes for reactive programs.
The look and feel of the widgets can be hard-coded in the toolkit, but some widget toolkit APIs decouple the look and feel from the definition of the widgets, allowing the widgets to be themed. (see pluggable look and feel).