GLG Toolkit Architecture Overview


The power and flexibility of any modern software tool depends on its internal architecture. The cleanness and expressive capability of the internal model defines many of the external characteristics of a software tool -- its performance, ease of use, and adaptability.

While many software packages rely on complex structures with deep hierarchies of objects to achieve relatively simple program behavior, the GLG Toolkit, a graphics toolkit for creating complex animated drawings and user interfaces, is built around a different model. Using a small number of easy to learn concepts and objects, the GLG Toolkit can achieve very complex program behavior by allowing the same simple objects to be used and reused in many ways. Instead of defining a rigid hierarchy of objects to use with a limited interconnection capability, the Toolkit provides a small number of objects and object actions with unlimited interconnecting capabilities. This allows users to build complex drawing structures from simple components.

The GLG model shortens the initial learning curve, since you can start experimenting with GLG objects right away. Later you can start building more and more complex drawings by creating complex connections as you go along.

GLG Toolkit Design Principles

The organizing philosophy of the Generic Logic Toolkit might be described as one of "relentless abstraction." A small number of data objects are used for a large number of tasks, making object reuse and generalization a central organizing principle of the system -- instead of just a useful feature. This provides a tremendous flexibility to the architecture, allowing it to apply equally well to simple and complex tasks.

The Generic Logic Toolkit is organized around a is based on the following design principles, described in detail further down on this page:

Object Model

Everything Is an Object
Attribute Objects and Constraints
Composite Objects and Recursivity
Groups and Layers
Reference Object
Viewport Object and Window Hierarchies
Native Window Objects
Interaction Handlers

Resource Based Data Access

Objects are Resources
Accessing Resources through Resource Hierarchies
Resource Persistence

Transformation Based 3D Motion Dynamics

Transformational Approach to Motion Dynamics

A transformation object can be attached to an object to move, rotate, scale or transform that object in some way. Transformations are not the only way to define an animation in a GLG drawing, but they are a simple and intuitive way to do so.

Changing the attributes of an object's transformations moves that object in the way defined for that transformation. There are translation, rotation, and other types of dynamics. For example, when you change an angle of the object's rotate transformation to rotate it, all necessary graphical updates -- transforming object points and redrawing the object at a new position -- will be handled by the Toolkit automatically.

The attributes of the transformation object, which control how the attached object is changed are inherently dynamic and can be accessed as resources. You can control these resources in precisely the same way you control the resources of any other GLG object. For example, a rotation object can be attached to a polygon to rotate it. The rotation transformation has two attributes, the angle of rotation and the center around which the rotation is defined. You can control these two attributes dynamically by changing their value with the GetResource and SetResource functions, just the same way you would control the fill color of the polygon or the position of one of its vertices.

All transformation objects operate in 3-dimensional space. Object rotation, for example, may be done around any of the X, Y or Z axes. Several transformations may be attached to any object or set of objects, allowing you to create complex 2D and 3D animations.

A transformation object may be applied not only to drawing objects such as polygons, circles, rectangles and so on, but also to an object's individual points or even to object attributes. For example, one point of a polygon may move while other points stay unmoved, or a rectangle's color could "rotate" through three-dimensional color space. On a more practical level, an indicator animation could change color as it moved to show passage of different levels (for a fuel gauge, red could indicate "almost empty" and green for "full").

Constrained Dynamics

The attributes of a transformation object can be constrained, in the same way any other object's attributes can be constrained. A constraint links a transformation attribute to another drawing attribute, making the two operate as one. For example, after constraining the rotational centers of several transformation objects to one another, moving that single point moves the whole thing. (And that point itself might be linked to another GLG object.) A complex model of a spoked wagon wheel might contain many objects, each of which might be linked to a rotation transformation to make the wheel spin. If the centers of all these transformations are linked, then moving the entire wheel is as simple as moving the rotational center. (To accomplish the same effect, you could also link all the wheel components to the same rotation transformation object. With a powerful architecture like GLG's, there may be more than one way to model any particular problem.)

Modeling Complex Behavior

The combination of graphical primitive objects, transformation objects, the mechanism of constraints and unlimited recursivity enables a user to create very complex drawings from a small number of relatively simple components. The simple elements -- drawing primitive objects, containers, references, transformations and constraints -- can be combined endlessly to model virtually any graphical system. Since there are no limitations on how these components can be interconnected, your creative capabilities aren't limited either.

The GLG ready-made graph and input widget objects are examples of intricate objects with complex behavior built completely in the GLG Builder with no programming.

Inherent Data Driven Dynamics and Damage Repair

Inherent Dynamics
Automatic Damage Repair
Data Driven Update
Granular Update

Composite Model for Complex Objects

Custom Reusable Components
Resource-Driven Data Supply
Programming Components and Portability
C++ Class Library

Model-Driven Design