Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

Graphical Truffles: The Display Manager

From Higher Intellect Vintage Wiki
Revision as of 18:16, 2 September 2020 by Netfreak (talk | contribs) (Created page with "A major change is taking place on the screen, which your application might not even know about! With the help of the Display Manager, the user can use the Monitors control pan...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

A major change is taking place on the screen, which your application might not even know about! With the help of the Display Manager, the user can use the Monitors control panel to rearrange displays, make resolution switches, add or remove a display, and move the menu bar from one display to another -- all without rebooting. However, the ease of changing a display for the user poses new challenges for the developer if an application relies on a graphics

device's bounding rectangle to position, zoom, and grow its windows.

To meet this challenge, the Display Manager provides several new functions that make it easier to gather information about the display environment and implement changes. I'll describe some of the more commonly used functions in this column. I'll also discuss how to use a notification event to find out when a display has changed (an example is included on this issue's CD).

Two versions of the Display Manager are currently implemented in the system software. The information in this column applies to both versions. Display Manager version 1.0 is available on all PowerPC(TM) processor-based Macintosh computers and Color QuickDraw-capable Macintosh computers running System 7.5. Display Manager 2.0 is available on PCI-based computers running System 7.5.2. To determine whether the Display Manager is available, call Gestalt with the selector gestaltDisplayMgrAttr and check the gestaltDisplayMgrPresent bit of the response. To determine which version you have, call Gestalt with the selector gestaltDisplayMgrVers.

MORE FUNCTIONS, LESS CODE

The Display Manager includes several new functions that greatly simplify tasks that used to take a lot of code. For example, many applications need to query screen devices for bounding rectangles, pixel depths, and a variety of other things. Prior to the Display Manager, an application could use the GetDeviceList function to retrieve the first graphics device record in the device list and call GetNextDevice for subsequent devices in the list. The application would then need to use the Device Manager to determine whether the device was a screen device and whether it was active. With the Display Manager, you can do all this with two functions: DMGetFirstScreenDevice and DMGetNextScreenDevice.

GDHandle      aDevice;

aDevice = 
   DMGetFirstScreenDevice(dmOnlyActiveDisplays);
while (aDevice != nil) {
   // Do something with the device.
   ...
   // Get the next device in the list.
   aDevice = DMGetNextScreenDevice(aDevice, 
                        dmOnlyActiveDisplays);
}

The Display Manager also introduces two functions that make it easier to retrieve information about the attached displays and to change their characteristics:

DMCheckDisplayMode and DMSetDisplayMode.

DMCheckDisplayMode determines whether a specific display mode and pixel depth are supported by the supplied graphics device. (A display mode is a combination of several interrelated display characteristics, such as resolution and scan timing.) This function has two output parameters: modeOk and switchFlags. If the Boolean modeOk parameter is true, the screen device supports the requested display mode. The switchFlags parameter contains two flag bits that should be checked with the constants kNoSwitchConfirmBit and kDepthNotAvailableBit.

  • If kNoSwitchConfirmBit isn't set, the requested mode is an optional mode and is only shown in the mode list of the Monitors control panel when the Option key is pressed (an optional mode requires confirmation from the user before it's allowed).

  • kDepthNotAvailableBit indicates whether the requested pixel depth is available with the requested display mode.

Once your application knows

that the requested display mode and pixel depth are available, you can use the DMSetDisplayMode function to reconfigure the video display. If you pass 0 for the mode parameter, the Display Manager uses the device's current display mode.

If you like to change the display mode and pixel depth often, you can save the configuration and retrieve it at startup with the DMSaveScreenPrefs function. This function requires three parameters, which all take the value of NULL since they're private to the Display Manager. (Go figure.)

Identifying displays. Many of the Display Manager functions require a display ID (type DisplayIDType) as a parameter. A display ID is a long integer that uniquely identifies a screen display. Affiliating a display ID with a graphics device can be useful in cases where the graphics device might change or isn't available. You can obtain a display ID with the function DMGetDisplayIDByGDevice, which requires a graphics device as a parameter. Or you can retrieve the graphics device corresponding to a given display ID by calling DMGetGDeviceByDisplayID. Both functions require the Boolean parameter failToMain.

  • If you set failToMain to true and the routine can't find what it's looking for (either the graphics device or the display ID), the routine returns information about the main graphics device rather than returning an error.

  • If you set failToMain to false and the routine can't find what it's looking for, it will return kDMDisplayNotFoundErr. (For example, when a PowerBook goes to sleep, the display might be removed.)

KEEPING UP WITH THE CHANGES

Now that the user is able to change a screen display without restarting, your application may want to reposition and resize its windows, update internal display-related data structures, or update nonstandard window definitions on

the fly.

If desired, the Display Manager can automatically adjust the positions of the windows that were onscreen before the change to keep them onscreen after the change, but it may not put them in the best possible positions. However, if you want to reposition and resize your windows yourself, you need to set the isDisplayManagerAware flag in your application's SIZE resource and install a callback procedure or an Apple event handler in your application so that you'll know when a display has changed.

Your application registers a callback procedure with the Display Manager function DMRegisterNotifyProc. The display notification procedure takes a Display Notice Apple event parameter describing the changes that were made to the display. The notification callback is especially useful for control panels and other instances where high-level event handling in an event loop isn't possible. Another benefit of the notification callback is that your application is informed on a more timely basis than through a high-level event, thus giving the appearance of seamless integration with the Display Manager.

    If you're using Display Manager 1.0, you're not notified about depth changes, and A5 isn't restored when you receive the notification callback.*

You can also receive and process Display Notice events through an Apple event handler. Display Notice event handlers are installed like any other Apple event handlers, with the AEInstallEventHandler function:

err = AEInstallEventHandler(kCoreEventClass, 
   kAESystemConfigNotice,
   NewAEEventHandlerProc(DoAEDisplayConfigChange),
   0, false);

To enable high-level events in your application, you need to set the isHighLevelEventAware flag in the SIZE resource. (You'll also need to support the required Apple events described in Inside Macintosh: Interapplication

Communication.)

Whether your application uses a notification callback or a high-level event handler, a Display Notice Apple event is passed to your routine. You can obtain a list of descriptor records (an AEDescList) from the Display Notice event with the AEGetParamDesc function. Each descriptor record holds two additional keyword-specific descriptor records:

  • keyDisplayOldConfig, which is a record of the display's previous state

  • keyDisplayNewConfig, which is a record of the display's current state

You can obtain these records one at a time with the function AEGetNthDesc.

To move and resize your application's windows, you need to know which graphics device was affected, the old and new bounding rectangles of the device, and possibly the pixel depth. All the information about the affected graphics device can be obtained from the descriptor list with keyword-specific descriptor constants, which are defined in the Displays.h universal header file. You call AEGetKeyPtr with the various descriptor constants to extract the information you need. In particular, the constant keyDeviceRect extracts the bounding rectangle, and keyDisplayID extracts the display ID. As previously mentioned, you can convert a display ID to a graphics device with the function DMGetGDeviceByDisplayID.

Listing 1 shows an example of what to do after receiving a Display Notice event from a notification callback or a high-level event handler.

Listing 1. Handling the Display Notice event

OSErr HandleNotification(AppleEvent *event)
{
   OSErr            err;
   GrafPtr         oldPort;
   AEDescList      displayList, aDisplay;
   AERecord         oldConfig, newConfig;
   AEKeyword         tempWord;
   DisplayIDType   displayID;
   unsigned long   returnType;
   long            count;
   Rect            oldRect, newRect;

   GetPort(&oldPort);

   // Get a list of the displays from the Display Notice Apple event.
   err = AEGetParamDesc(event, kAEDisplayNotice, typeWildCard, &DisplayList);

   // How many items in the list?
   err = AECountItems(&displayList, &count);

   while (count > 0) {
      // Loop through the list.
      err = AEGetNthDesc(&displayList, count, typeWildCard, &tempWord, &aDisplay);

      // Get the old rect. 
      err = AEGetNthDesc(&aDisplay, 1, typeWildCard, &tempWord, &oldConfig);
      err = AEGetKeyPtr(&oldConfig, keyDeviceRect, typeWildCard, &returnType, &oldRect, 8, nil);

      // Get the display ID so that we can get the GDevice later.
      err = AEGetKeyPtr(&oldConfig, keyDisplayID, typeWildCard, &returnType, &displayID, 8, nil);

      // Get the new rect.
      err = AEGetNthDesc(&aDisplay, 2, typeWildCard, &tempWord, &newConfig);
      err = AEGetKeyPtr(&newConfig, keyDeviceRect, typeWildCard, &returnType, &newRect, 8, nil);

      // If the new and old rects are not the same, we can assume that the GDevice has changed,
      // and the windows need to be rearranged.
      if (err == noErr && !EqualRect(&newRect, &oldRect))
         HandleDeviceChange(displayID, &newRect);

      count--;
      err = AEDisposeDesc(&aDisplay);
      err = AEDisposeDesc(&oldConfig);
      err = AEDisposeDesc(&newConfig);
   }

   err = AEDisposeDesc(&displayList);
   SetPort(oldPort);

   return err;
}

WHAT TO DO NOW

The sample code on this issue's CD should provide a starting point for how to handle display notification events in your application. Additional documentation and sample code for the Display Manager are provided in the Display Manager Development Kit, which is also on the CD.

    The Mac OS Software Developer's Kit incudes the Display Manager Development Kit along with a lot of other development software. The Mac OSSDK is now part of the Developer CD Series (included in the Apple Developer Mailing, which is available through the Apple Developer Catalog).

To learn more about what the Display Manager can do for you, you should also

take a look at the Displays.h universal header file.

Now there's no excuse for your application to be in the dark about changes taking place on the screen. So why not keep your users happy and take advantage of the help that the Display Manager can give you?