| Open Architecture
A
number of Adobe applications support the Open Architecture (MOA). MOA provides a rich multimedia platform for both Adobe
and third parties to build on to extend application
functionality. The components of this architecture
are described on in this document.
Adobe Portable Object Model
MOA
is based on the Adobe Portable Object
Model, which defines a way to declare interfaces
that are implemented by classes. This model
is compatible with the Component Object Model
defined by Microsoft as the basis for OLE 2.
In addition to the model, MOA provides a highly
portable COM implementation that supports in-process
objects on both the Macintosh and Windows.
MOA
objects consist of 1) a set of private variables
defined by a developer to keep track of relevant
data, and 2) an implementation of one or more
interfaces, each of which defines a table of
virtual functions that provide the behaviors
supported by the MOA object.
MOA
objects are designed to be dynamically loaded
into an application. They are the fundamental
building blocks of Xtras, which contain functionality
that can be plugged into Adobe applications.
Application users simply drag Xtras into their
application's Xtras folder to augment its functionality.
Adobe Xtras API
Adobe
Xtras API enables developers to provide value-added
extensions--Xtras--for many Adobe applications.
The real breakthrough of this architecture
is the development of Xtras that work not only
across the Windows and Macintosh platforms
with little or no platform-specific code, if no product specific interfaces are used, but
will also work across multiple products (such
as a Transition Xtra that works in both Director
and Authorware). By having an architecture
that is both cross-platform and cross-product,
a third party creating an Xtra is assured of
broader usage and bigger markets.
Xtras
are the most visible and tangible result of
the MOA for day-to-day
users of Adobe products. Some Xtras are
product-specific, while others are designed
to work across multiple applications. The table
below provides a sampling of how the Xtras
can be supported in Adobe applications
and where those Xtras appear in each application's
user interface.
| Director
Xtras |
Appears
In |
Behavior |
|
| Transition |
Transition
Dialog |
Performs
screen transition effect. |
| Asset |
Insert
Menu |
Creates
an instance of an add-in media type. |
| Scripting |
Lingo
scripting language |
Provides
additional functions and objects in the
Lingo scripting language
|
| Bitmap Filters |
|
|
|
| |
| Authorware
Xtras |
Appears
In |
Behavior |
|
| Transition |
Transition
Dialog |
Performs
screen transition effect. |
| Asset |
Insert
Menu |
Creates
an instance of an add-in media type. |
| Pixel
Filter |
Graphics
Editor |
Runs
filters (Photoshop and others) that can
modify bitmaps. |
| Scripting |
Authorware
functions |
Provides
additional functions and objects to Authorware
functions |
|
| SoundEdit
Xtras |
Appears
In |
Behavior |
|
| Effect |
Effects
Menu |
Changes
one or more characteristics of existing
sound data. |
| Generator |
Insert
Menu |
Creates
new sound data. |
| Importer |
File:
Import Menu |
Imports
sound data into SoundEdit from a specific
type of source file. |
| Exporter |
File:
Export Menu |
Exports
sound data from SoundEdit to a specific
type of file or document. |
|
| FreeHand
Xtras |
Appears
In |
Behavior |
|
| Pixel
Filter |
Xtras
Menu |
Runs
filters (Photoshop and others) that can
modify bitmaps. |
| Tool |
Xtra
Tools palette |
Interactively
creates or edits graphic elements. |
| Command |
Xtras
Menu
Xtra Buttons palette |
Performs
operations on graphic elements or documents
as a whole. |
| Palette |
Xtra
Windows menu |
Persistent
floating window to allow for dynamic operations,
status windows, etc. |
| Importer |
File:
Open dialog
File: Import dialog |
Imports
graphics from a specific type of source
file. |
| Exporter |
File:
Export dialog |
Exports
graphics to a specific type of file or
document. |
|
Connecting Xtras
The
Adobe Xtras API supports rich, well-defined
suites of functionality. One cornerstone of
the architecture is the clear delineation of
responsibilities between applications and Xtras.
On the application side, this means providing
a coherent way to expose internal data structures
and behaviors to Xtras. On the Xtras side,
this means providing modular units of behavior
with the correct plugs to fit into corresponding
application sockets. To support this, MOA uses
interfaces- a standard means of defining the
modules of functionality that an application
or Xtra provides.
A
second cornerstone is the provision of cross-application
standards that define the interaction between
applications and Xtras as generally as possible,
to encourage developers to create Xtras that
work across applications. For example, both
Director and Authorware provide Xtras with
access to the drawing surface of the display
in precisely the same way.
All
MOA-capable applications support a basic set
of callback interfaces, which enable an Xtra
to access standard services, including memory
allocation, stream access, and simple user
interface tools:
| MOA
Callback Interface |
Description |
|
| IMoaCalloc |
Allows
an Xtra to allocate bytes of fixed memory
in the host application's heap. |
| IMoaHandle |
Allows
an Xtra to allocate bytes of relocatable
memory in the host application's heap. |
| IMoaFile |
Provides
cross-platform access for reading and writing
files. |
| IMoaStream |
Allows
an Xtra to read and write a byte stream
passed to a MOA object. |
| IMoaProgressBox |
Allows
an Xtra to display a progress dialog using
the host application's dialog system. |
|
Similarly,
all Xtras implement a set of cross-product
interfaces so that they can register themselves
and be installed into applications in a generic
way.
| Xtra
Interface |
Description |
|
| IMoaRegister |
Allows
an Xtra to register itself and store initialization
data. |
| IMoaInitFromDict |
Allows
an Xtra to initialize an instance of itself
from stored data. |
|
Adobe Multimedia,
Graphics, Audio
Functionality
that is similar across applications is gathered
into a common set of interfaces which can be
accessed by Xtras, allowing a single Xtra to
be used in multiple Adobe applications-even
those released after an Xtra was created.
Adobe
defines a set of shared callback interfaces
that are supported by Adobe multimedia
applications. These interfaces are called by
Xtras to invoke specific multimedia functionality
inside an application (such as adding a new
asset type to Director or Authorware). All
applications that support multimedia implement
these interfaces and can therefore share Xtras.
Multimedia
Callback Interface |
Description |
|
| IMoaMMGC |
Provides
access to platform-specific features of
an application's drawing surface. |
| IMoaMmAssetCallback |
Provides
asset-specific support from the application. |
| IMoaMmChangeCollector |
Provides
methods for improving drawing efficiency. |
| IMoaMmCuePointCallback |
Provides
a way for Xtras to signal cue points to
an application. |
| IMoaMmMacEventHandler |
Connects
an Xtra to the application's event handling
on the Macintosh. |
| IMoaMmPropOwner |
Defines
general property access methods. |
| IMoaMmWndMac |
Provides
access to platform-specific windows on
the Macintosh. |
| IMoaMmWndWin |
Provides
access to platform-specific windows on
Windows. |
| Xtra
Interface |
Description |
|
| IMoaMmXAsset |
Defines
media that can be plugged into an authoring
or playback system. |
| IMoaMmXSpriteActor |
Manipulates
a particular asset that is being played
back over time. |
| IMoaMmXTransitionActor |
Defines
screen transitions. |
| IMoaMmXScripting |
Defines
scripting language extensions. |
| IMoaMmXTool |
Defines
authoring features available from Tools
menu. |
| IMoaBitmapFilter |
Defines the Bitmap filters that can be applied from Property Inspector. |
|
Adobe Apps
Adobe's
core technologies provide the foundation for
Adobe applications, forming the most extensive
set of dynamic media building blocks in the
industry. Adobe applications give Xtras
access to these core technologies through product-specific
interfaces for the internal data structures
and major processing loops in those applications.
This allows FreeHand Xtras to access splines,
Director Xtras to access cast members, and
SoundEdit Xtras to access sampled data streams.
Each
application-specific Xtra provides an interface
that can be called from its associated application,
to provide information about the state of the
Xtra processing and to provide appropriate
information to the application display in dialogs
or menus. Examples of product-specific interfaces
include:
| Application |
Callback
Interface |
Description |
|
| Director |
IMoaDrCast |
Gets
cast-level info and invoke behaviors on
entire casts.
|
| Director |
IMoaDrCastMem |
Gets
info and invokes behaviors on individual
media assets.
|
| Director |
IMoaDrScoreAccess |
Accesses,
traverses, and edits the Director score.
|
| SoundEdit |
IMoaSEService |
Accesses
the sound data being edited.
|
| FreeHand |
IMoaFhCallback |
Gets
info on and modifies the graphic elements
in a FreeHand document.
|
|
| Application |
Xtra
Behavior |
Description |
|
| Authorware |
IMoaAwSaveState |
Enables
Xtras to support pausing and resuming an
Authorware piece. |
| FreeHand |
IMoaFhToolItem |
Defines
drop-in tools for a FreeHand editing window. |
| FreeHand |
IMoaFhMenuItem |
Defines
menu commands for FreeHand. |
| FreeHand |
IMoaFhButtonItem |
Defines
an action-button command for FreeHand. |
| FreeHand |
IMoaFhReaderItem |
Defines
a file importer for FreeHand.
|
| FreeHand |
IMoaFhWriterItem |
Defines a file exporter for FreeHand. |
|
|