Software Review - Ad Lib 1.0b4

Jeffrey J. Barbose

First there was text-based (Rez) creation of 'view' resources for MacApp development. Then came ViewEdit: graphical creation of views. Simple 'view' format, simple tool. Next was IcePick, which pushed the state of the art of graphical editing systems, exploiting every nook and cranny of the MacApp 2.0 'view' definition with style, finesse and power. When MacApp 3.0 and the new robust and highly functional 'View' format came along, IcePick dropped the ball, to this day still not providing for direct creation of 3.0 views. The kludgy mechanisms provided by Apple to maintain compatibility with 2.0-view formats, coupled with the fact that use of the new view format provided substantial conceptual and productivity gains forced a reticent retreat to buggy, awkward yet 3.0-view-supporting ViewEdit.

Prayers for an alternative to ViewEdit for editing 3.0-views ostensibly had been answered with the introduction of Ad Lib. Arguably, it exploits all the goodies associated with 3.0 'View's, but with a confusing menu bar, scattered access to view attributes and some rough edges on the data entry mechanisms, it's certainly no panacea for view-editing woes. Put another way, it represents one step up and two steps back in MacApp view editing.

Overview

The Menu Bar

One of Ad Lib's more confusing qualities is the layout of its menus, which will be described in detail. But first, a cursory look:

• File – in addition to the standard HIG-compliant menu items, a Preferences item is available. (Figure 1)
• Edit – includes items for clipboard-base manipulation of views as well as several view-specific items for creating, opening and accessing information in views.
• View – not to be confused with a menu that contains items for 'View' manipulation, this menu rather provides for customization of behavior of Ad Lib itself with respect to how the 'View's being built are displayed.
• Object – this menu provides for the manipulation of 'View's with respect to their hierarchy, inheritance, placement and attachments.
• Window – provides access to Ad Lib's floating windoids (see Figure 2), and also contains the list of all currently open windows.

As you can see, direct 'View' manipulation is spread out over three of Ad Lib's five menus, requiring the user to memorize their locations. Some reorganization is in order here.

The Floating Windows

Ad Lib uses three separate floating windows (or windoids) to provide special functionality (see Figure 2):

• Object Palette – a very well done-if non-standard-presentation of all possible MacApp standard view types. Each view type is represented by an icon well (much like Double Helix™'s icon wells or the tab-wells found in many word-processors' rulers). New views are added by dragging the icon for the desired view type into the view-in-progress, where they can subsequently be placed and resized.
• Attributes – contains most view-specific attributes. Another point of confusion arises here: why not put all attributes within this windoid? Instead of having such access to all view-specific attributes, the user must select the Class Hierarchy item from the Object Menu, which produces a hierarchical menu specific to the selected 'View's inheritance. (There is, however, an interesting and very helpful behavior having to do with en masse view editing that will be explained later.)
• Information – in the unzoomed configuration, it provides only the coordinates of the current mouse position, expressed relative to the currently selected view. When zoomed out (which should be the default), it also provides a magnifying-glass or 'fat-bits' view in the cursor's neighborhood. This is invaluable for lining up view boundaries and for resolving aesthetic anomalies.

The Cool Stuff

Ad Lib significantly extends the boundaries of resource-creation tools, both in terms of bridging the gap between static resource editor and dynamic environment, and providing context-specific 'intelligence'.

At first blush, apparently (and conspicuously) missing is the functionality of IcePick's famed 'Run-Time Mode', in which the views could be 'run' to see what they'd look like and how they'd perform (in limited ways), without having to incorporate them into an executable application. Instead, Ad Lib provides the means of attaching TAdorners, TBehaviors, TDrawingEnvironments, etc., to the views at the resource level (thanks to 3.0-'View's), and further provides what the documentation calls handlers "…[which] are powerful, general purpose behaviors that allow your views to respond to specific messages by sending new messages to various objects within your program." (Ad Lib Preliminary Documentation).

These handlers are somewhere in between TCommands and TBehaviors in their functionality. They respond to messages or triggers (e.g., button hits, menu selections), and consequently generate an event or perform a simple action.

Ad Lib allows for view run-time testing by using MacApp itself to run the prototyped views, along with their associated behaviors, adorners, handlers, and so on. Several source files ship with Ad Lib that extend MacApp to support behaviors-as-resources, as well as for attaching behaviors to the application object itself. To the point, a bare-bones TApplication-specifically, the derived class TBehaviorApp which ships with Ad Lib-becomes the testing environment for nascent views.

With MacApp 3.x, text strings and style information for views were moved into separate resources, allowing such information to be shared among any views in the application. Ad Lib does some serious bookkeeping for you with these resources, in that it checks for identical resources and opts to use those instead, eliminating redundancy. In Ad Lib, text and style information is entered directly, as you would in any word processor or text editor. This mechanism is far superior to ViewEdit's two-step method of creating text and style resources and associating them with views through resource IDs. Ad Lib will then create (or reference, if the resource already exists) the appropriate resources for you. There are some caveats to watch out for when editing these resources outside of Ad Lib, but Ad Lib uses an internal time-stamp and so can detect when changes were made by another editor. If the file was, in fact, changed by another appli-cation, Ad Lib suggests a rebuilding of the resource count tables (see Figure 3) before proceeding (this is highly advised in order to avoid text and style resource corruption).

The Paradigm

For all its attention to making the minor things work according to standard Macintosh Interface Guidelines (as in direct entry of text strings and styles), Ad Lib takes on an odd, pseudo-modal paradigm in navigation of the created view tree(s). Rather than providing an addition view (Á la the Finder's Outline View or IcePick's Hierarchy View) for traversal, Ad Lib instead has a double-click, separate-window mechanism for discerning, navigating and altering the view hierarchy. This user action, when used repeatedly to chase down deeply-nested views, results in quite a number of stacked windows (which later need to be closed manually). It smacks, oddly enough, of WordPerfect 1.0's penchant for nested dialogs and old-style DOS-like menu screens. Some people may find this the most natural and comfortable way of doing things, but judging by the praise heaped on the System 7 Finder's Outline View, I'd say they were in the minority.

The Hooks

As mentioned above, Ad Lib ships with several source code files (see Figure 4), including an example of how to use Ad Lib and the MacApp derived classes as a run-time view testing environment. The files contained in the 'MacApp Extensions' Folder implement the functionality that Ad Lib's handlers require. The following classes are supplied:

• THandlerBehavior – derived from TBehavior, provides Ad Lib-style message handling (user-defined actions) to your objects;
• TBehaviorApp – attaches any behaviors (specifically 'BHVR' resources) to the application object;
• TBroadcastCmdKey, TCmdKeyBehavior – proves an easy mechanism for attaching command-key equivalents to your controls;
• THandlerInitMsgCmd – used internally to initialize handler messaging;
• HScratch – used internally as temporary storage for messaging information.

The 'Prototyping Example' Folder contains the files necessary for building an application called ProtoApp. ProtoApp can be used as the environment for run-time testing of your views (and related resources) by adding the code for any behaviors you may have created and including your view resources to it.

Provided as an example of specific view testing is TestApp. By following the instructions in the README file, a ProtoApp is built and the specific view resources for TestApp are then simply rezzed into it.

Ad Hoc Ad Lib

A better feel for Ad Lib can be had by specific examples. To that end, Ad Lib will be put through its paces, both in its view sketching mechanics and usability, and in terms of its organizational and informational facilities.

A Simple(?) Scrollable Window

One of the most common view types in any Macintosh application is the standard horizontally- and vertically-scrolling window. Once Ad Lib is launched, the user is presented with an empty window which contains a list of the newly created views (see Figure 5). This is the dialog that's presented every time a new window or new view is created using the Edit menu (subviews, however, are almost always created from the Object Palette). As you might expect, the resource ID is suggested by Ad Lib for each view/window to avoid duplicates.

After this dialog is dismissed, an empty window appears on the screen (see Figure 6 on the next page). With Ad Lib, windows are created like any other view, and displayed as such (unlike IcePick and ViewEdit, where the TWindow is a special case). To access or change the specific attributes of the window, open the Attributes windoid from the Window Menu. This floating window contains the only the most frequently accessed attributes of a TWindow. Here you can set size, position, title and WDEF number, among other basic things. To access the remaining TWindow attributes, go to the Object Menu's Class Hierarchy item. Here you will see, in reverse order, the complete inheritance of the currently-selected object (in this case, TWindow). Selecting from this hierarchical menu presents a dialog containing the specific definable fields (see Figure 7 on the next page). This mechanism presents some serious difficulties to the new Ad Lib user, since all attributes are not in any one place. Also notice that the information contained is not mutually exclusive (see Figure 7). ViewEdit's approach to this, while mechanically cumbersome, makes more sense to the user in that all view information can be accessed in one place.

Before creating any view hierarchy, Ad Lib's utility windoids should be used (available from the Window menu):

• show the Object Palette windoid;
• show the Information windoid and zoom it out so that the magnifier view is also shown;
• show the Attributes window. Get in the habit of supplying necessary information (like view ID) as soon as the view is added to the hierarchy.

To make this window scroll properly, we need to create the familiar MacApp hierarchy: the main subview of the window is a TScroller, which extends from the origin of the content region to the topLeft of the GrowIcon; the TScroller should be set to sizeRelativeSuperView in both dimensions; and a single TView (sizeFixed or sizeVariable) drawn inside the TScroller that will serve as the root view for the enclosed view hierarchy. Ad Lib takes an interesting perspective on TScrollers: they are considered attachments to a view, like Adorners or Behaviors, not equals with other view types. Consequently, the approach to creating a scrolling view is this:

• Drag a TView icon from the Object Palette and drop it in the window.
• In the Attributes windoid, give the view a unique ID (such as 'main'), and set the location to (0,0). You'll see the small TView change location as you do this.
• Grab to bottom right handle of the new view and drag it down to the upper left of the GrowIcon. As the first attempt at aligning it properly, just get it near to the GrowIcon and then use the magnifier view to fine tune. (see Figure 8) Notice that the Information windoid shows current cursor position, the magnified view of area around the cursor, and the ID of the view that the cursor is presently in.
• Since the TView is already selected, select the 'Scroller…' item from the Object menu. Again the user is presented with only the most frequently used attributes to edit. Here, the scrollability of the view can be set (the user must check the 'View Has Scroller' box since it defaults to false), as well as the number of scrollbars (if any) and some of their attributes. (see Figure 9next page )
• To access additional fields of the scroller (it is frequently necessary to access the TView-level fields of TScrollers), you must select the TView item from the Class Hierarchy item of the Object menu. The TScroller's ID must be set. For a scrolling resizable window, the TScroller's size determiners must be set to 'Relative to Superview', so that the scroller's size always changes when the window is resized. Note that the size determiners of the TView to which this TScroller is attached should be set to something other than sizeRelativeSuperview or to sizeSuperview; otherwise, there's no need for scrolling!

This is a lot of work to do, just to get basic scrolling into a standard Macintosh window. The process would be much more efficient here if access to attributes was collected into or accessible from a single place. The notion of a scroller being an attachment to a view turns out to be more encompassing than the traditional notion of TScrollers treated as just another view type: by attachment of a conceptual scroller, one gets the scrollbars and enclosed view as a single addition. Some mechanization of the process of attaching a scroller would also speed things up considerably. Ad Lib could easily prompt the user for all the necessary information, or better, have a canned scrollable view or window available.

In lieu of that, included on the Frameworks Disk Subscription for this issue is a file named 'Simple Window.view'. This file contains the view resource defined and created above.

Complex Ad Libbing

Development of complex views using Ad Lib presents unexpected challenges, as well as benefits. Creating complex view resources involves three primary activities:

• View sketching and view hierarchy traversal;
• Attachment of needed resources (Behaviors, Adorners);
• Wiring the views and their resources into TBehaviorApp for testing (and as final implementation, in some cases).

The most glaring omission from Ad Lib's view editing arsenal is that of an outline view for traversing and editing the nascent 'View' hierarchy. Instead, it offers two distinct ways of accessing views-within-views, depending on whether the 'Subview Access' item in the View menu.

First, the view hierarchy can be 'flattened', so that all subviews are accessible by clicking on them while the 'Subview Access' item is on. This kind of direct access works in most cases, but can get cumbersome and even confusing when the hierarchical arrangement is crucial to the operation of the view (such as radio buttons within a cluster). For instance, if 'Subview Access' is on, newly added views become subviews of the view that they're dropped into. If 'Subview Access' is off, the views are added as direct subviews of the window (or topmost view, if there's no window). To add to the confusion here, views can be brought to the front or moved to the back, neither of which changes the actual view hierarchy.

The alternative way of traversing and editing the hierarchy is with the 'Subview Access' item off. In this 'mode', only the views which are direct subviews of the current view can be selected. When a view is selected and the View menu item 'Edit Subview' is chosen, a new window opens. This new window is a placeholder for the subviews of that selected view. In Figure 10, the window entitled "<TCluster>" represents the extent of the cluster behind it and contains the cluster's subviews, namely, three checkboxes.

While this second method clears up any ambiguities in hierarchical organization, for deep view trees the screen can get cluttered with stacked placeholder windows very quickly (anyone remember WordPerfect for Macintosh 1.0?)

By selecting multiple views, certain mathematical alignment operations can be performed on the views as a group. (Figure 11) While adequate for basic cases, this method of auto-alignment falls far short of IcePick's Aligning, Spreading and Same-Sizing of clustered controls/views.

Attachment of additional resources to the views is accomplished mostly from within the Object menu using various dialogs to supply needed information. Adorners and Behaviors are added by a similar mechanism. Through respective dialog boxes, they can be specified, added, removed and ordered. For example, in ViewEdit, the ordered firing of adorners was limited to 'First', 'Last', 'Before' or 'After'. Here, the order of adorners in the dialog's list determines the exact order in which adorners will be called (see Figures 12a, 12b). Plus, Ad Lib automatically adds an instance of THandlerBehavior (described above) to each view to which handlers have been added (see Figure 13). Simple attachments like Drawing Environments, Balloon Help references and text (where applicable) are available through equally simple dialogs.

Ad Lib handlers are also added through a dialog, but the purpose in adding handlers is to provide 'wiring' to your views for the run-time environment. Ad Lib supplies the code, handlers and message types for several common triggers: Apple Command, Command Key, Event, Idle, Initialize, Key Down, Key Up, Menu Command, Mouse Down, Mouse Up, Setup Menus and Update. The trigger type is selected from a popup menu and added to the handler list with a button click. Upon adding a trigger, additional information must be supplied, most importantly the action that this handler should take upon receiving the message. These actions are: Add Dependent, Close, Close & Free, Depends On, Doesn't Depend On, Enable Menu, Forward Message, Open Window, Pose Modal Dialog, Remove Dependent, Send Event, Send Menu Command, Send Update, Set User Value and User Defined. Most of these action types aren't documented (in the beta docs), but their meanings can be gleaned, if not simply by their name (e.g., Open Window) then by the nature of the information requested. A target must be specified in many cases (such as any of the 'Send…' actions). Valid targets are: Application, Document, Self, Subview, Superview, Target Chain, View, View (by Window), Window and Window (by ID). A short text description of the specific action can be supplied as well (see Figure 14).

This method of entry proves difficult in some situations because certain conventions must be followed to insure the proper flow of messages within the handler system. For instance, two handlers for each menu item must be created, namely a 'Setup Menu' handler to deal with enabling the menu item and a 'Menu Command' handler to dispatch the message to the proper resources and targets. For each of these operations, the user must not only be sure that all menu items are taken care of, but that a dummy handler forwards the message to 'self' (for those times when the message is to be resignaled or wasn't serviced by any handler). If you have a solid grasp of MacApp-style event handling chains, there really isn't a conceptual problem here. The difficulties arise in entering all this information through a dialog/list interface. Graphical entry of the messaging passing/routing chains would make more sense here.

Also included on the Frameworks disk is 'Complex Window.view'. It includes a simple window (containing a TPicture), the complex-view window described above, and a handful of other resources that were required as add-ons to ProtoApp:

• an 'MBAR' resource (ID=128);
• a 'PICT' resource, used in the TPicture views;
• a 'CMNU' resource (ID=4) to supply menu items (which trigger the opening of our windows).

After adding these resources to the Ad Lib .view file (and having already built ProtoApp), it was a simple task of Rezzing it together with the ProtoApp file to produce a working application (drag the files 'Complex Window.view' and 'Amoco.r' to the 'Prototyping Examples' Folder within your Ad Lib folder)-far less effort than I had originally expected.

Ad Lib::DoPostCreate()

In general, Ad Lib does a very good job of helping to create, edit and manage all of data that 3.0 'View' resources are equipped to deal with. Usability could be significantly improved by a simple reorganization of the menubar, but perhaps the greatest improvements lie in consolidation of access to view attribute fields. As it stands, the user is often required to look in two places-sometimes many more places-to edit attribute fields of interest. And note that each of those places is a modal operation, something not looked highly upon by the Human Interface Police (and with good reason).

Small, but important, improvements can be made in automating some of the tasks into gestalts. For instance, in the creation of a scrolling view, the user could be prompted for pertinent information at the time the scroller is attached to a given view (and this is yet another place that better access to attributes would help, with or without automation).

However, I don't feel comfortable in ending a review of Ad Lib with criticism. It's a fine first version, and its coverage of 3.0-View enhancements is impressive indeed. Some of the paradigms it introduces, while not altogether traditional or standard, work quite well once grasped.

Given the current choices-use ViewEdit, go the IcePick->ViewPromoter->manual-hacking-of-view-attachments route, or get Ad Lib and use it immediately-well, there really is no question. And, for now, there really is no other editor besides Ad Lib. n

Thanks to G. Gordon Apple for his postings on AppleLink demonstrating certain caveats and to-dos associated with attaching scrollers and with post hoc deleting of scrollbars. Thanks also to Tom Tulinsky for prompting certain specific investigations into Ad Lib.