Introducing Bedrock

No it’s not Fred Flintstone, but it is at least as important as Fred is to developers!

By Patrick Rigney, Director of Core Technology, Symantec Corporation

Over the past decade, a number of Graphical User Interfaces (GUIs) have become popular in desktop and workstation computing. On PCs the most notable GUIs are Apple’s Macintosh System Software and Microsoft’s Windows.

As the demand for GUI-based applications has increased, so has their complexity. Users demand powerful functionality, access to the latest operating system and hardware features, and What You See Is What You Get (WYSIWYG) editing. For developers, the GUIs’ Application Program Interfaces (APIs) present a broad range of functionality, a substantial portion of which must be learned to build such complex applications. Applications that were once small and manageable by one or a small number of engineers now require a larger team. Software developers are searching for solutions to these problems.

ENTER BEDROCK

Bedrock is a library of C++ classes and tools that provide a toolkit and an object-oriented application framework. An application framework is a skeleton application that contains functionality common to most applications. The developer builds an application on top of this framework.

Bedrock’s mission is to reduce the time and effort spent on many complex yet common cross-platform issues, and to provide simpler interfaces to system features (such as the Clipboard and AppleEvents), allowing more time to be spent on quality, maintainability, or additional features that make the application stand out.

Many of Bedrock’s classes are designed to hide implementation details of the target platform from the application. In effect, Bedrock acts a translator between the application and the Macintosh and Windows systems, taking high-level requests and invoking the appropriate forms for each platform. While Bedrock hides these issues, it still allows the developer free access to them when necessary. Application code written on top of Bedrock can coexist with code written directly to the platform.

Bedrock also provides classes and methods for features specific to individual platforms. This points out another major goal of Bedrock: to provide simplified interfaces to complex system functionality. Without these, Bedrock would be reduced to a “least common denominator” solution.

A LAYER- AND COMPONENT-BASED DESIGN

The Bedrock design allows the developer to use pieces that best suit the application’s needs. Conceptually, Bedrock’s classes are segregated into four layers, each of which contains various components. A component is an abstraction that contains one or more C++ classes and provides a related set of capabilities.

The architecture is layered to organize the information flow between layers. The components of an upper layer request services from and depend upon the lower layers, but components in the lower layers do not call components in the layers above them. Figure 1 shows a sampling of the major components in their parent layers.

Figure 1. Bedrock Layers

This layer-and-component architecture actually makes Bedrock appear and function like many small class libraries, rather than one large one. The relationships between layers and components are more formal and distinct, as opposed to the Microsoft Foundation Classes (MFC) and Apple’s MacApp, in which most classes are derived from a single root class. This makes the framework easier to learn, and more scalable.

THE APPLICATION FRAMEWORK LAYER

When using Bedrock, much of the programming time is devoted to building on top of classes in the Application Framework layer. This layer contains the Application, Document, Clipboard, and Chore components, which are highly interdependent. For example, if the developer changes the way the document component works, this application component will likely also need to be changed.

The Application

Bedrock’s Application component provides the structure of functionality common to most GUI applications, including support for application-level menu items in the File, Edit, and Help menus, the Apple menu on the Macintosh platform, and managing undo/redo of tasks. The Application component depends on the GUI Layer of Bedrock to dispatch events and provide the user interface, and on the Document component to control windows and the user’s access to data.

The Document

The application framework model of Bedrock has been strongly influenced by the Macintosh and Windows document architectures. The document is responsible for directing the interaction between the data and the user’s view of that data. It supports document-level commands in the File, Edit, and Help menus, printing, undoing of commands, and multiple open documents.

Clipboard and Scrap

The Bedrock clipboard is closely tied to the document. The document creates a scrap object, which is copied to the clipboard. The scrap object knows what formats it can translate to and from, and knows how to install a view in the Clipboard window to view the current contents of the clipboard.

Bedrock supplies some common scrap objects, including a text object, a Macintosh PICT object, and a Windows MetaFile object. This functionality is extended by providing a scrap object that knows how to deal with new data types.

Chores

Chores are tasks that are performed at various times in the application. Bedrock provides an implementation for the following kinds of chores:

• Timer chores-executed at a regular intervals, specified at creation time.

• Idle chores-performed whenever the application is not performing any other tasks.

• Urgent chores-performed immediately, whenever they are assigned.

Chores can be used in limited circumstances to simulate multi-threading.

Actions

Actions are typically created in response to events, such as choosing the “Cut” command from the Edit menu. They provide basic protocol and interfaces for managing changes to the document’s data. The application object can track the last action committed and will direct it to undo in response to a user’s “Undo” command.

A mouse action is created in response to a mouse button press. The mouse action object continues to exist, providing such functions as visual feedback, until the user releases the button.

An action informs the application whether it is undoable and should be tracked, because some actions are normally not considered undoable (e.g. saving a file or resizing a window).

THE GUI LAYER

Besides the all-important concept of the Application Framework layer, Bedrock provides a layer to handle the GUI. The components in this layer include Event Handling, Menus, Views, Windows, Controls, Cursors, Carets, Icons, and Drag/Drop.

Event Handling

A characteristic of modern event-driven systems is that users can choose to take any of several actions at any one time. These actions, which are typically menu choices, button selections, and keystrokes, result in the generation of operating system events. Procedural applications typically trap the event and take action on it based upon a switch statement somewhere in the event dispatching loop.

System events trigger the creation of a Bedrock event object, which is dispatched to an event-handling object. Every event-handling object has a supervisor, which is also an event handler. The supervisor is specified when the event handler is instantiated. If an event handler does not wish to handle an event, it passes it on to its supervisor.

Behaviors are objects that can be associated with an event-handling object at runtime. They may be associated with a particular instance of an object, or an entire class of objects. When an event is dispatched to an event handler, Bedrock first looks to see if an instance or class behavior can handle the event, before looking at the static event handling methods. This mechanism provides a way to add or change event responses at runtime. For example, a behavior can be added to a button that allows it to be dragged when clicked, as opposed to the normal “execute command” behavior associated with buttons.

The highest-level event handler in Bedrock is the application object, which supervises the application desktop and the event handlers for dialogs.

Views

Every object that can appear on the screen (with the exception of some menu objects) is drawn within a view. As the highest level visible object, views have the following properties:

• Are contained in a visual hierarchy,

• Can be hidden, shown, resized and clipped,

• Can be enabled or disabled,

• Can receive the focus, and it can receive mouse clicks and keyboard events,

• Can change background color,

• Can change cursor shape as the mouse passes over it,

• Have a local coordinate system.

Every view has an enclosure, which is another view that usually encompasses every visual point of the enclosed view. An enclosure always owns all of its enclosed views. This enclosure relationship results in a runtime hierarchy referred to as the visual hierarchy. The application desktop is at the top of this hierarchy, and typically encloses one or more windows. In turn, the windows enclose one or more views. Bedrock uses this hierarchy to dispatch mouse events to views and to handle activation/deactivation of views.

A scroller is a special class of view that can be used when the visual representation of data is larger than the allotted visual area. The scroller knows how to scroll its enclosed subviews in response to the user’s actions; conversely, these subviews do not need to know how to scroll. Scrollers are typically associated with scrollbars, and manage all interaction with them. Scrollers also manage scrolling via autoscrolling (that is, dragging the mouse) and the keyboard (for example, Home, End, Page Up, and Page Down keys).

Canvases

Bedrock renders views on a canvas. There are four major canvases in Bedrock: window, printer, metafile, and bitmap. Each implements a common rendering interface, allowing a view to be drawn on either a window or a printer by merely switching the target canvas and telling the view to draw itself.

Each canvas also implements specific behavior for its type. For example, windows can be tiled, cascaded, iconized, and obscured by other windows. Bitmaps and metafiles can be in-memory or disk-based.

Controls

Controls in Bedrock are views that encapsulate the platform’s native controls, so the buttons look like Macintosh buttons on the Macintosh and Windows buttons under Windows.

Bedrock provides scroll bars, buttons, checkboxes (including tri-state checkboxes), radio buttons, push buttons, group boxes, static text controls, edit controls, and list boxes.

Dialogs

Dialogs consist of a dialog box, a director, and one or more subviews (typically controls). The appearance of a dialog conforms to the GUI standards for the platform. Bedrock supports Modal and Modeless dialogs on both platforms, and Application Modal dialogs on Windows.

A director acts as the mediator between controls. For example, a director may enable the “Open” button on a dialog in response to a file name selection in a list box. In addition, directors handle keyboard navigation and default button presses.

Bedrock provides the following dialogs:

• Color Selection

• Open File

• Save File

• Confirm File-Close

• Confirm File-Revert

• Font Selection

• Printer Setup

• Print Job Initiate

• Print Job Progress/Status

Menus

Bedrock allows the developer to create multiple menu bars, and alternate between them by sending messages to the desktop.

Bedrock supports pull-down , pop-up , bitmap and custom-drawn menus. Each menu can have other menus added to it, or removed from it, as well as have individual menu items added. Menus and menu items can also be enabled and disabled (with appropriate highlighting changes occurring automatically).

Text Editing

Bedrock supplies basic text-editing capabilities. This component is useful mainly in the context of controls containing editable text.

Cursors, Carets, and Icons

Every view has a cursor associated with it. The cursor associated with the view will be displayed whenever the mouse is positioned over a visible region of the view. The application can create any number of cursors, but only one may be associated with a view at a given time.

A caret (usually marked with an I-beam cursor) marks the current insertion point in text. Bedrock provides the caret in its default text-editing services, and provides methods for setting the caret in a text view.

Icons are one of the significant characteristics of a GUI. Bedrock provides support for loading icons from resources and displaying them in a view.

Drag-and-Drop Support

Drag-and-Drop is the ability to drag “objects” (data) between locations. A good example of this is in the Macintosh Finder, which allows the user to delete a file by dragging its icon to the Trash.

Bedrock fully supports the Drag-and-Drop feature, both within an application (between views) and between applications, on both platforms.

THE OPERATING SYSTEM LAYER

Bedrock provides basic components that help hide the underlying operating system from the application. At this layer, the application will normally be using the services that Bedrock provides, with little subclassing or overriding.

Components in this layer include Graphics Support, System Configuration, Memory Management, Files, and Resources.

Graphics support

Bedrock supports platform-independent drawing with the following primitives: Line, Polyline, Rectangle, Rounded Rectangle, Region, Ellipse, Chord, Pie, Arc, Bitmap, Picture (Macintosh PICT and Windows MetaFile), Icon, and Text.

Bedrock also provides a logical coordinate system that supports translation and scaling. By default, Bedrock’s coordinate system defines the origin as the top left corner of the view. The coordinate system can easily be changed as necessary. to accommodate, for example, Cartesian coordinates with the origin at the bottom left. In addition, it is possible to independently transform and scale the x and y axes.

System Configuration

The system configuration abstraction provides information about the system upon which the Bedrock application is being run. Thus, the application can request system-wide (as opposed to application-specific) attributes and actions, such as current directory, screen resolution, or (on the Macintosh) hardware configuration flags (Macintosh Gestalt information).

Memory Management

Bedrock provides a general-purpose allocation scheme that shields the developer from the details of managing memory across platforms. Bedrock’s allocator requests large blocks from the system and suballocates them on demand to the application. When freed by the application, adjacent free blocks are coalesced in to larger blocks.

Bedrock objects are pointer-based. Handle-based objects are not supported.

Files

The Bedrock file components provide platform-independent file I/O and uniform handling of errors. The FileAccess component is extensible to allow network- or memory-based random access to data.

Resources

Most applications use resources to store small pieces of code or data that can be changed without recompiling the application. For example, all strings used by an application can be stored in resources for easy localization.

Bedrock supplies tools to improve the portability of resources. The Bedrock Resource Compiler (BEDRC) takes resources defined in Bedrock resource statements and compiles them into the native resources of the platform. The Bedrock Resource Language syntax is an extension of Apple’s Rez language, adding type declaration (typedef statements) and complex type creation (struct, class, union). The syntax is C++ compatible, and the compiler supports the ANSI C preprocessor directives, allowing it to read and derive type information directly from C++ header files. The developer can then use these new types in resources.

Bedrock’s resource mechanism allows the application to instantiate objects by name from a resource definition. For example, a view hierarchy may be defined in a Bedrock resource, and later be instantiated by name from the resource file. By modifying the resource file, users can modify the view hierarchy without recompiling the application.

THE FOUNDATION LAYER

Bedrock’s Foundation Layer provides basic services to the higher layers, or directly to application code. The components at this level are largely independent of one another. The Foundation Layer components, in turn, depend only upon the facilities of the C++ language. These components include Streams, Sinks, Strings, Collections, Exceptions, and International support.

Streams and Sinks

Streams provide a generalized interface for reading and writing data, including protocol for higher-level entities (integers, floats, strings, and so on), and thus provide platform- and device-independence for all kinds of I/O. Streams are generally heterogeneous; that is, they operate on many types of data.

Streams read from and write to sinks. A sink is a “device” that can be a source or destination for a stream of bytes. Sinks provide only a byte-oriented, untyped interface. Bedrock provides file sinks and memory block (resizable and nonresizable) sinks. Sinks may be extended to construct, for example, serial interface sinks and network interface sinks.

Strings

A string is a run of text, composed of characters. Strings always use characters as the units of transfer, so type-safety is guaranteed and access is fast and efficient. Bedrock stores characters in Unicode format, and provides ways to export characters to other character systems such as ASCII.

International Support

Bedrock provides support for localization through resources (as discussed earlier), writing systems, and locales.

A writing system encompasses all the information a Bedrock application needs to edit, display, store, and retrieve text strings. It depends on the locale abstraction to supply basic information such as date format, thousands separator, and so on.

Together, the writing system and the locale track and implement script properties, sort orders, word-breaking and boundary behavior, mapping and translation tables, and formatting for times, dates, and numbers.

Data Structures and Collections

Bedrock’s collections are a subset of the Rational C++ Booch Components, consisting of Collection, Ordered Collection, Map (a dictionary of domain/range pairs), Queue, Stack, and Tree.

Tools and iterators are used to act on a collection. Bedrock includes tools for searching and sorting collections.

Collections, tools and iterators are implemented using C++ templates, and can therefore store and operate on any data type, rather than just objects.

Exception Handling

The components in each layer detect errors that the application must handle. In those cases where the library does not know how to handle an error, it can throw an exception object. The application can catch this object and respond.

Bedrock’s exception handling is based on that described in The C++ Programming Language and The Annotated C++ Reference Manual (ARM). The Bedrock Exception Library (BEL) is included to emulate this mechanism on compilers that do not support ARM Exception Handling. BEL’s syntax is slightly different from the ARM syntax, but is designed to easily translate to that syntax. When using a compiler that supports C++ exceptions, one can remove the BEL emulation.

BROAD RANGE OF FUNCTIONALITY

Bedrock’s varied components provide a broad range of functionality to the application developer. Complexity in the framework is reduced by layering the components, which helps organize their interactions. Within the layers, each component acts as a class library in itself, making the entire system easier to learn and use.

By combining this architecture with the general benefits of object oriented programming, Bedrock provides cross-platform capabilities and simplifies the interface to system features (both cross-platform and platform-specific). The developer using Bedrock can more quickly deliver high-quality applications on both the Macintosh and Windows.