X window manager
|This article relies largely or entirely upon a single source. (November 2011)|
Unlike the Mac OS (Apple Macintosh) and Microsoft Windows platforms (excepting Microsoft Windows explorer.exe shell replacements) which have historically provided a vendor-controlled, fixed set of ways to control how windows and panes display on a screen, and how the user may interact with them, window management for the X Window System was deliberately kept separate from the software providing the graphical display. The user can choose between various third-party window managers, which differ from one another in several ways, including:
- customizability of appearance and functionality:
- consumption of memory and other system resources
- degree of integration with a desktop environment, which provides a more complete interface to the operating system, and provides a range of integrated utilities and applications.
When a window manager is running, some kinds of interaction between the X server and its clients are redirected through the window manager. In particular, whenever an attempt to show a new window is made, this request is redirected to the window manager, which decides the initial position of the window. Additionally, most modern window managers are reparenting, which usually leads to a banner being placed at the top of the window and a decorative frame being drawn around the window. These two elements are controlled by the window manager rather than the program. Therefore, when the user clicks or drags these elements, it is the window manager that takes the appropriate actions (such as moving or resizing the window).
Window managers are also responsible for icons. Indeed, icons do not exist at the X Window System core protocol level. When the user requests a window to be iconified, the window manager unmaps it (makes it non-visible) and takes the appropriate actions to show an icon in its place. Most modern window managers do not literally show icons to represent iconified windows anymore. Often, an auxiliary toolbar program will allow access to iconified windows.
While the main aim of a window manager is to manage the windows, many window managers have additional features such as handling mouse clicks in the root window, presenting panes and other visual elements, handling some keystrokes (e.g., Alt-F4 may close a window), deciding which application to run at start-up, etc.
Standardized protocols exist to allow normal clients to communicate with the window manager. The original one is Inter-Client Communication Conventions Manual (ICCCM) but this has been superseded by the Extended Window Manager Hints (EWMH).
A stacking window manager renders the windows one-by-one onto the screen at specific co-ordinates. If one window's area overlaps another, then the window "on top" overwrites part of the other's visible appearance. This results in the appearance familiar to many users in which windows act a little bit like pieces of paper on a desktop, which can be moved around and allowed to overlap.
In contrast to compositing window managers (see below), the lack of separate off-screen buffers can mean increased efficiency, but effects such as translucency are not possible.
A tiling window manager is a window manager with an organization of the screen into mutually non-overlapping frames (hence the name tiling), as opposed to the traditional approach of coordinate-based stacking of objects (windows) that tries to emulate the desk paradigm.
A compositing window manager may appear to the user similar to a stacking window manager. However, the individual windows are first rendered in individual buffers, and then their images are composited onto the screen buffer; this two-step process means that visual effects (such as shadows, translucency) can be applied. It also means that compositing window managers are inherently more resource-hungry than an equivalently-powerful stacking window manager. For this reason, some window managers for X do not support compositing by default, such as LXDE.
Historically, the Amiga in 1985, OSX in 2001 (which in many ways iscitation needed a window manager for X), Java Looking Glass in 2003, and the Windows Longhorn demo in 2003 (delayed until Vista in 2007) preceded compositing efforts under X11. Compositing window managers for X include:
- GNOME's Mutter nee Metacity (first dev-branch compositor in 2.7citation needed or 2.8  of 2004 —original stable-branch compositor since 2.14 in 2005  or 2006 —current compositor architecture since 2.22  in 2008—Metacity+Clutter begat Mutter in 2011),
- Xfce's Xfwm (since 4.2 of 2004citation needed or 2005 ),
- Unity's Compiz (since 2005—was forked as Beryl in 2006 but the projects re-merged in 2007), and
- KDE's KWin (since 4.0 of 2008).
A virtual window manager is a window manager that uses virtual screens, whose resolution can be higher than the resolution of one's monitor/display adapter thus resembling a two dimensional virtual desktop with its viewport. This environment is very useful when one wishes to have a large number of windows open at the same time. A number of virtual window managers have been made, including FVWM, Tvtwm, HaZe and others.
Some window managers are extensible, or programmable, by user scripts.
In these window managers, users can define new actions or override the default, or reactions to various events, like window size and position changes, window creation and deletion, key and mouse input, timer, etc. They often provide on-the-fly code execution, too.
Some examples of such window managers and the used languages are:
- 5Dwm (derived from mwm, true SGI look and feel)
- 9wm (clone of the original windowing system of Plan 9)
- amiwm (Amiga workbench unix clone)
- Blackbox (minimalist)
- evggww (Egg Window Manager - Qt based WM)
- EvilPoison (a fork of evilwm with Ratpoison-like keybindings)
- Fluxbox (lightweight, based on Blackbox)
- FVWM (a virtual window manager, derived from twm)
- Ion (a tiling tabbed window manager designed with keyboard users in mind)
- JWM (Joe's Window Manager)
- KWin (originally called KWM, default for KDE)
- luminocity (experimentation in compositing)
- Mutter (GNOME Shell) (the current default for the GNOME desktop environment)
- Metacity (the previous default for the GNOME desktop environment)
- mwm (Motif Window Manager)
- olwm (OPEN LOOK window managers)
- olvwm (olwm with virtual desktops)
- Openbox (default for the LXDE desktop environment)
- Orion (a nested (tiled or floating) window manager written in Scheme and scsh)
- Qvwm (Windows 95/98 look-alike)
- Sawfish (a past default for GNOME, originally called Sawmill)
- Scwm (the Scheme constraints window manager)
- SithWM evilwm-based, virtual window manager (German page)
- Stumpwm (a tiling window manager written in Lisp)
- swm (the original virtual desktop implementation)
- Toy'd (a portable window manager for MS-Windows & UNIX / Linux platforms)
- touchegg Window Manager (Qt based WM for multi-touch gestures )
- twm (default for the X Window System since version X11R4)
- Ultrix Window Manager
- Window Maker
- Xfwm4 (a window manager for the Xfce desktop environment)
- XPwm (for XPde, Windows XP Look alike)
- ZappWM, (based in Rox-filer)
- Comparison of X window managers
- Re-parenting window manager for a popular implementation technique
- X Window System protocols and architecture for context
- Windowing system
- Wmctrl - a command line utility used to control windows in EWMH and NetWM compatible window managers
- xdotool - another command line utility used to control windows
- Window Managers for X by Matt Chapman
- Software List:Window Managers - list of window managers with summaries
- The Comprehensive List of Window Managers for Unix