As suggested previously, a modal window is one that blocks user input to the window that it's above. This typically means it's placed in the center of a parent window and the window below will be disabled or grayed out, focusing the user interaction on the new dialog window. This is typical of dialog windows as they're designed to appear only when the user can't continue with the current task until the information, confirmation, or progress is completed (at which point the dialog disappears and control returns).

To function in this way, a modal window is usually passed the parent window that it should occlude. The input will be forced to the new modal window (depending on the desktop environment and configuration, this may not be the case if the parent window isn't currently the topmost application) to interact with the new interface. Different platforms can present modal windows using various styles; some will look like a regular window (often with maximize and minimize buttons disabled), others will present the content embedded within the current window, and others (such as macOS) can present them appearing from the title bar of the parent window. Using the built-in API for custom dialogs will mean that these visual styles are consistent within your application.

There may be a reason, however, that your application requires a new window to take focus in a different type of workflow. For these cases, a toolkit often allows the modality of a window to be set directly. This can be a powerful feature but be sure to consider whether there isn't a better API to manage this flow, or whether a custom dialog window may be a better fit.