Window Manager
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Window Manager
As noted under desktop environment, the exact role, function and nature of the window manager is uncertain. The possibility of different GUI “personalities” leads to the possibility of window management being divided into two or more levels, with the lowest level(s) being a routine library.
Caveats
This page is effectively concerned with overlapping window systems, versus (for example) tiling window systems. This does not necessarily mean that an overlapping window system will be the chosen approach or the only approach available.
Core roles
The core roles of the Window Manager relate to low-level operations.
Positioning
All calls to create, show, move, resize, maximise and restore a window will pass through the positioning routines. These routines ensure that the window remains in-bounds at all times.
The Window Manager creates new windows according to the position, size and role specified by the application. The position and size can both be deferred to the Window Manager by way of conditions such as using the same monitor as an existing window or the monitor containing the cursor, or according to the role of the window (e.g. automatic dialog box placement). The Window Manager will assess the specified size and determine what is necessary to accommodate the request, such as if the co-ordinates are off-screen or the window is larger than the monitor. The Window Manager will preferentially relocate the window such that all of it is on-screen; if this still fails, the window will be reduced in size as far as is necessary to fit on the screen, within the limits of the minimum size specified by the application.
To a certain extent, overrides will allow for forcing the specified co-ordinates, so long as the window is not going to be completely inaccessible.
Windows defined as shell-level (for example the taskbar) will be taken into account by all positioning requests. Photoshop on the Macintosh implemented “zoom” (see below) in an intelligent manner, in that floating tool palettes were taken into account when sizing the window. Illustrator on the Mac however implemented zoom very much like maximise in Windows, causing the document to end up partially obstructed by the tool palettes. Although it’s perhaps easier and more logical to keep tool palettes inside the document window, the zoom implementation is a good example of the nature of the Window Manager positioning algorithm in staying clear of all shell-level windows.
The diagram below shows a simulated Photoshop session with the Zoom button highlighted:
On pressing Zoom, the document window would enlarge to accommodate the free space on the screen:
This behaviour appears to be rare. IcoFX 2 was another program that implemented the same behaviour, within an MDI interface.
Linking
Linking associates one window with another, such that moving the parent window also moves the child window. This is used by tool palette windows that float to the side of the parent window rather than inside of it.
Grouping
Grouping associates windows with their parent, in particular a modal window with its parent window. The linking behaviour (above) also applies here: dragging a parent window will move an associated modal window (child window) and any further descendant windows.
Behaviours
The various behaviours implemented on existing operating systems are detailed below. A generic, personality-independent library is going to want to implement as many of these as possible, within reason. It would not be practical to add a title bar button for each of them as there too many different behaviours.
Maximise
Enlarge the window to fill all the space on the screen not occupied by the shell and other global windows.. The window title bar is retained, but not the border, and the window cannot be resized. In newer versions of Windows, the window can be moved by dragging its title bar, which automatically reverts it to its pre-maximised size.
Restore
Return the window to its pre-maximised size or, for a minimised window, from its minimised state.
Zoom (toggle size)
Implemented on classic Mac OS (and to a limited extent, Mac OS X), “zoom” is a request to resize a window according to its contents, within the limits of what will fit on the screen. For windows that have no limit on size or where the limit is already larger than the screen, the window is enlarged to (almost) fill the screen, specifically the space below the menu bar at the top (as opposed to true full screen that takes over the entire screen). The window title bar and border are retained and the window remains resizable, and resizing the window clears the zoom state.
The window never truly filled the screen; it was inset from the top, left and bottom screen edges by a small margin, and on the right edge by a gap large enough to always reach the right-most column of desktop icons, which by default contains all mounted volumes and the Wastebasket Trash.
A rare vertical-only version also existed (as shown above); this was used for the About This Computer window. Whether a horizontal-only version also existed is not known.
RISC OS called this button “toggle size”. Unlike zoom and maximise, “toggle size” fills the whole screen when there are no window content bounds to be applied; the following screenshot of !Draw under RISC OS shows this clearly, with part of the icon bar still visible due to the floating tool palette:
As with Mac OS, the window title bar and border are retained and the window remains resizable, and resizing the window resets the toggle state to custom.
Full screen
Fill the entire screen with the contents of the window, hiding all of the shell UI (e.g. global menu bar, taskbar) as well as the window’s title bar and border. On desktop and laptop systems this was historically only intended for specific use cases (e.g. playing games or watching videos) but has now become a staple of the macOS UI. Handheld computers typically ran full screen at all times as there was too little screen capacity for overlapping windows.
Send to back
Move the window to the back of the window stack. Implemented on the Amiga and RISC OS amongst presumably other systems. Although not possible with existing systems, this should move all associated modal windows at the same time, in that modal windows will block access to the content of the parent window but not its title bar. The validity of this function is questionable, as effectively it buries the window. Just as with WindowShade (below), it does not allow the user to toggle between two active windows using only the mouse; Alt+Tab or similar is still required for this.
WindowShade
WindowShade was a third-party add-on to Mac OS that allowed a window to be rolled up into its title bar by double-clicking the title bar. This add-on was merged into Mac OS 8 as a native feature complete with a new title bar widget dedicated to the feature. WindowShade (and the equivalent functionality on X11-based systems) allows a user to see—but not interact with—the contents of the window behind without losing their place in the window stack. Attempting to (for example) copy text from the window behind risks that window being raised above the rolled-up window. Rolled-up windows could conceivably be placed into an always-on-top status to mitigate this limitation.
Toggle toolbar
Mac OS X introduced a title bar button to toggle the window’s toolbar. This is akin to the widget under Microsoft Windows to toggle a window’s ribbon.
System menu
The “system menu” under Microsoft Windows is a menu associated with a window that provides commands (enabled according to window state) to move, resize, minimise, maximise, restore and close the window. Double-clicking the widget closes the window. Originally it was represented by a kind of dash symbol; from Windows 95 it was represented by the window’s icon. For ease of access, this menu is also available as the title bar’s context menu. The latter is retained in modern versions of Windows, while “metro” windows lost the corner icon that directly owns the menu.
Some “metro” programs (e.g. Calculator, Clock etc.) retained the icon but castrated it: it no longer opens the system menu, causing user confusion as double-clicking it maximises the window instead of closing it.
The menu does not appear on a title bar right-click until the mouse button is released, which means that it is fundamentally compatible with the RISC OS behaviour of dragging the window with the right (“Adjust”) mouse button to move the window without raising it. Implementing this behaviour under Windows is however not viable due to the number of programs that draw fake title bars.
Help
This widget was only available in dialog boxes and took the place of minimise and maximise. The intention was that you would click the Help widget, then click on a control in the window to receive a floating message with brief instructions; it could also take you to the relevant help topic. While still supported in at least Windows 10 (seen under Internet Options), the world has largely abandoned the idea of context help and anything that might lead you to relevant documentation, and use of the Help button has dwindled to nothing. Nowadays you are expected to reach out with your feelings and locate some worthless egg-sucking-grandma help topic somewhere on the Interwebz instead.
Additional features
Proxy icon
A proxy icon is an icon placed into the title bar to represent the file or folder in turn represented by the window. Dragging the proxy icon (which involves a long press first to indicate that the drag is intended for the proxy icon and not the title bar) will move the associated file or folder without needing to first close the window and locate the item. Holding down the Command key while clicking the window’s title (not just the proxy icon) reveals a menu of the parent and ancestor folders and the enclosing volume for the item; this behaviour pre-dates the use of proxy icons. For documents it was typically for saved/unsaved status to be indicated by whether the proxy icon is solid (saved) or faint (unsaved). The icon is not a true proxy in that it is not a drag-and-drop target nor can you open a context menu on it.
File Explorer under Microsoft Windows implemented a similar icon just for folder windows, placed into the address bar instead of the title bar. The icon in title bars under Windows represents the window’s system menu (Move, Minimise, Restore etc) and not the underlying document.
Window icon
This is an icon associated with the window for use on the title bar (for the system menu), taskbar (prior to window grouping and when window grouping is disabled) and for Alt+Tab. This is distinct from proxy icons on the Mac in that the icon represents the window as a whole (which can be a program icon or document icon according to context) and is not restricted to windows that directly represent objects on disk.
Custom widgets
In some cases there is a desire to add a custom widget to a title bar. This may be application-specific or applied to all windows. For example, UltraMon adds a widget to move a window between monitors:
Under Microsoft Windows, these widgets tend to be fully custom-drawn and do not inherit any styling from the OS. This is the first mistake. It should be possible to add a custom widget to a specific windows or all windows of a specific core class (document, modal window etc) and in the process inherit the general appearance of the system.
Failure to inherit the system theme will result in a rather incongruous widget:
UltraMon cheated by floating the widget above each window’s title bar, guessing as to where it should be placed. This broke when applications already added custom widgets, and there was a fudge offset that you could set on a per-program basis to compensate. This can be seen in the following screenshot where Outlook has malfunctioned and Windows has drawn a replacement title bar, and UltraMon has preserved the custom offset even where it is not needed (and note the separate vertical offset bug):
If the window’s title bar ended up the wrong height (if that, too, is fake) you also have a problem:
Microsoft Office windows are all fake anyway, with a non-native appearance. Here you have a mixture of two different fake widgets:
This is a later UltraMon version that was programmed to accommodate Windows 10 upwards (and possibly 8 upwards); there is a custom widget from Office and another from UltraMon:
With that said, there is no realistic way to ever make this work properly. With Microsoft Windows, you mostly need to inherit the border and background along with the symbol colour and the styling used when the widget is inactive. There are however some very distinct boundaries that cannot be crossed, such as symbolic (Windows, RISC OS) versus colour-coded (macOS) widgets. There is simply nothing that can be done to allow a custom widget to match any system theme.
Application layer groups
Apple System Software 7 through Mac OS 9 placed each application’s windows into a layer group:
Interleaving windows between applications was impossible. Clicking on any window belonging to another application would bring that window to the front of that group, then move the whole group to the front. An interesting benefit of this was that it was fundamentally impossible for a program to place a modal window in front of another application’s window: modal windows would remain within the owning application’s layer group. The program would signal for attention by alternating its icon with that of the active application in the menu bar or by showing a modeless floating alert window. Selecting this application would bring all of its windows to the front:
Mac OS X finally allowed windows to be interleaved and for windows to be minimised (to the Dock) but if anything, the end result was more frustrating rather than less. Minimised windows were excluded from Exposé window selection and from keyboard access.