1. Introduction Under AmigaOS, a program window is always open on a screen. The operating system’s graphic environment can use multiple screens at the same time, providing a number of “virtual desktops” for you to work on. Screens may vary in size (resolution), colour depth, and they can also be mouse-dragged to reveal other screens hiding behind. Amiga programs can use their own, private (called “custom”) screens; they can open a “public” screen to share display with other programs; or they can open no screen at all and instead use another program’s public screen as visitors. Quite naturally, the most popular and most visited public screen is the Workbench. Amigans have always been very proud of their screen system. It’s a well-established concept that hasn’t changed much throughout the years, unlike other parts of Intuition. Yet from a programmer’s point of view, screens have been redefined in AmigaOS Release 4. Well, not the screens per se – it’s the philosophy of their use that has changed. The following article helps understand the current mindset and explains certain new implications for screen programming and usage. 2. Past to present In the past, Amiga programs made a heavy use of custom screens. As the resolution of the computer display was low – the typical screen resolution of the time was mere 640x256 pixels – one could quickly lose overview when having too many programs on the Workbench. It was, therefore, normal that individual programs opened their own screens, through which the user switched as needed. To that end software developers often provided screen configuration as part of their programs’ settings. But now that AmigaOS-compatible computers use high-resolution displays with 16- or 32-bit depth, custom screens have become less useful than before. Why is that? Well, there are now a number of convincing reasons to open programs on the Workbench by default (especially if their GUI consists of a single window). First of all, a large Workbench can comfortably accommodate most programs you typically run during your computing session. Plus, the race for space on the Workbench has become less of an issue with the emergence of modern applications that are able to collapse (“iconify”) their windows to occupy next to no space on the screen. Moreover, running programs on the Workbench brings the benefit of accessibility: you do not need to swap screens to access other programs, disks or the handy features of OS4’s docking utility, AmiDock. Last but not least, using multiple large screens can really be taxing resource-wise. On some lower-end systems you may quickly run out of graphic memory and bring the OS to a crawl just because a couple of programs decided to open their own screen. Sharing a common public screen – such as the Workbench – is more economical. 3. Screens in AmigaOS 4.x The decline in the importance of custom screens (brought about by hardware innovations) has further been accelerated by two new AmigaOS features that, instead, encourage the use of public screens: 3.1 Automatic public screens AmigaOS 4.x received a new Preferences editor, Screens, which unfortunately seems to have been escaping the attention of many. The editor allows users to pre-define their own set of named public screens to utilize throughout the system. They are virtual, “automatic screens”: they exist as screen definitions known to Intuition, and are only opened when a program requires them. Let’s say you have a screen called “MyPublicScreen” pre-defined in the Screens editor, as the image below shows: Now if you provide the following tag in your window creation code

...
WA_PubScreenName, “MyPublicScreen”,
...

if ( !(pubScreen = IIntuition->LockPubScreen("AnyName")) ) pubScreen = IIntuition->LockPubScreen(NULL);
if (pubScreen)
 {
  /* you can safely reopen your window now */
 }

• If your program uses a simple GUI, always open on the Workbench by default.
• If you want to give users the option to open on a separate screen, let them define the screen parameters themselves using AmigaOS's Screens editor. In your program’s Settings, provide a string gadget for the public screen name. Alternatively, if your program has no Settings section in the GUI and uses Application Library’s XML-based preferences format, provide a key named “Public Screen” (or similar) for the users to enter the screen name. They can easily edit the prefs file with a text editor or the dedicated PrefsObjectsEditor located in the system's Utilities drawer.
• If your program must use a dedicated screen by default (typically: programs that open many sub-windows), open a public screen via OpenScreenTags(). In your program’s Settings, provide a standard screenmode selector and a checkbox option letting the user to clone the Workbench screen parameters (you’ll do this by passing “SA_LikeWorkbench, TRUE” in the OpenScreenTags() call). Make Clone Workbench the default setting.
• Remember that automatic public screens created through the Screens prefs editor are user-defined. As such, the program(mer) can never quite rely on their parameters. For example, if you write a program that runs on an automatic screen called "MyProgScreen", this screen will likely be defined differently on individual users' systems. So if your program requires a screen of a certain depth, size etc. to function properly, you should open the screen yourself and not rely on the Screens editor.
• Do not use custom screens unless you absolutely have to. Expect that the user will want to open various programs on your screen.
• Do not keep public screens locked throughout program runtime. Call UnlockPubScreen() when your program window (re)opens.
• Be smart and careful in your code that handles window iconification and uniconification. Never assume that your program’s window will reopen on the same screen. Do not keep any global pointers or locks that refer to the original screen or its properties.
• Now that windows can jump freely to different screens, caching screen pointers does not make any sense. It never did, actually. Always query the window object using GetAttr() when you need the current screen pointer.
• Use Intuition's GetScreenAttr() or GetScreenAttrs() to find out about screen properties.