Desktop environment

Contents

• Personality
• Concepts
  • MDI vs SDI

Personality

Consideration has been given to the idea of providing different personalities to the desktop experience. In particular, features such as a taskbar will be separate modules that can be exchanged for alternatives or removed entirely (so long as something exists to handle the required functionality).

This would make way for complete personalities, such as mimicking Windows, KDE, RISC OS or the Mac. Each personality would introduce suitable modules, such as the Windows taskbar, RISC OS icon bar or the Mac OS 9 application switcher. This goes far beyond simple themes, whose role is simply to restyle the existing interface without altering its implementation.

There is however a significant problem with this idea that may render it impossible. To achieve a high-quality interface that is extensively consistent, applications must be expected to make use of standard UI services. This does not work well if applications are dependent on concepts that are missing from other systems entirely. The differences in behaviour between different systems are so vast that there is no way to reproduce them on another system

Difficult questions are raised regarding the boundaries of responsibility. For example, there is a lot of core functionality required for window management. When a program asks to show a window, the window manager must make sure that the bounds are valid, and move or resize the window to most closely accommodate it within the user’s monitor arrangement. (Anyone with a top taskbar will attest to how abominably Windows handles this and, really, all window management.) Methods and safeguards need to exist to stop focus theft by windows opening unexpectedly.

A lot of the window management basics can be relocated to a library, with the personality module left to accommodate all the personality-specific behaviours that got overlooked by the library. This would help address concerns such as how the entire menu system is personality-dependent. Quite where this line is drawn is unclear, as so many tasks have multiple incompatible implementations. The macOS Dock, Mac OS Application Switcher, Windows taskbar and RISC OS Icon Bar are all completely different.

The Mac OS Control Strip, macOS menu bar and Windows taskbar notification area (“system tray”) are all different. Apple’s equivalent to the system tray is a portion of the menu bar set aside for global menus, while tray icons in Windows have no defined purpose whatsoever, and a left-click on one may open a window, show a menu or do nothing at all. The Control Strip has buttons with sub-regions that function independently, for example the volume control entry has + and − buttons within the same item, while most items are buttons that open a menu.

Allowing personalities opens up a can of worms in that applications will have no single system behaviour to target, and may misbehave when running under a different personality. Although flexibility is a principle of the system as a whole, ultimately most users are expected to use a single overall experience, so that knowledge and experience can be shared between people readily, be it friends and neighbours, or when working with technical support staff.

The distinction between such notions as “Desktop Manager” and “Window Manager” seems nebulous and needs to be more closely defined.

Concepts

MDI vs SDI

Early versions of Windows introduced the concept of the multiple-document interface (MDI): a single parent window that contains inner windows for documents. By contrast, single-document interface (SDI) applications present each document as its own independent top-level window. Alt+Tab was introduced to switch between top-level windows, and Ctrl+Tab provided switching between child windows within an MDI parent window.

The Macintosh has an intriguing concept where it is impossible to start two instances of the same application. Programs and processes are not separate notions to the user: a program is either running or it isn’t. As such, a Window menu is needed to select between the application’s windows. Cmd+` cycles between windows of the same application, supposedly (the Mac UI model was broken horribly in Mac OS X).

The primary question becomes: is there a single, good model that all applications can adopt? The next question therefore is: can the model differ by personality, or is this not practical in terms of how applications are to be structured? To support the Mac model, all applications would be expected to support multiple concurrent windows; with a personality using a distinct-process model, the same program would need to recognise that its preferences could be amended from another process.

There is a precedent here. JujuEdit is a single-document text editor (each window has its own process) that uses a Window menu as though all windows belonged to the same process (albeit with a buggy implementation), Ctrl+Tab cycles between windows of the various JujuEdit processes, and it understands the idea of the configuration and state being shared between multiple processes.

The real question is more a matter of integrity, safety and stability. Depending on the workload, it can be much easier and much safer to implement a single-document model. This avoids the need for complex threading and thread safety and needing to manage multiple simultaneous complex data models. Should any process fault, none of the other processes for that program will fail. A single-document model is not going to support the Mac model without a lot of troublesome complexity; JujuEdit has a decent compromise but having commands like Quit reliably apply to all processes of the same program properly (simulating them all being the same process) would be difficult.