This is the mail archive of the
mailing list for the Cygwin project.
[ANN] OpenAmulet 4.3
- To: cygwin at sourceware dot cygnus dot com
- Subject: [ANN] OpenAmulet 4.3
- From: Paul Sokolovsky <paul-ml at is dot lg dot ua>
- Date: Thu, 28 Oct 1999 21:16:39 +0300
- Reply-To: Paul Sokolovsky <paul-ml at is dot lg dot ua>
OpenAmulet GUI Toolkit, version 4.3 has been released. This version
features (for win32) DLL support, made fully with gnuwin32 tools
(mingw32 target). I would like to thank Cygnus for egcs and supporting
latest C++ in it, and for supporting win32 with cygwin; and Mumit
Khan, for mingw32, dllimport/dllexport in egcs, and answering how to
make it work with every new version of compiler ;-)
To be more informative, some kind of blurb (somewhat lengthy and
OpenAmulet, free cross-platform GUI Toolkit version 4.3
Why yet another GUI toolkit?
First of all, it's not yet another GUI toolkit, it's *the* GUI toolkit.
OpenAmulet is based on previous work of Amulet project
(http://www.cs.cmu.edu/~amulet/) held by User Interface Software Group
in the Human Computer Interaction Institute in the School of Computer
Science at Carnegie Mellon University (Brad A. Myers, Ellen Borison,
Alan Ferrency, Rich McDaniel, Robert C. Miller, Andrew Faulring,
Bruce D. Kyle, Patrick Doane, Andy Mickish, Alex Klimovitski). Amulet is
their second toolkit, the C++ redesign of Garnet, written in Lisp and
being classical example of nice and functional design.
One of the intentions of writing Amulet in C++ was popularizing ideas
not available to large audience and pushing it to production needs, in
addition to research and educational ones.
What are distinguishing features?
Briefly, OpenAmulet utilises Prototype-Instance (vs Class-Object)
object system, uses Constraints as the means to maintain system's
state and actions, and provides detached behaviour-oriented
More specifically, OpenAmulet emphasizes data-oriented programming.
While "classical" (or, precisely, C++'s) object design preaches data
hiding and interfacing via methods, Amulet has it "upside-down": all
interfacing held via object's properties, and methods has only
auxillary, system-internal role. Amulet has means to support such view
of the world:
* Prototype-instance object model
Class-object model distinguishes two kinds of entities: 'classes',
which can be instantiated, but not used, and 'objects' with opposite
features. Prototype-instance approach doesn't have this distinction:
any object can be both used as entity ready for processing and for
instantiation of subobjects. Hence, class-object model is just
constrained form of prototype-instance model, having stipulation
above. Of course, Amulet object system is fully dynamic, allowing
creation of new types of objects at runtime.
* Demons and constraints
How is it possible to interface via data? That's because it's
possible to watch some object properties (or slots) and act upon
changes. Low-level mechanism for this is demons. They are supposed
to be eager and low-latency. For example, when size/position of
graphical object changes, attached demons queue changing region for
More high-level notion is constraint. Ideally constraints are
mathematical equations, though may have side effects. With
constraints slots of different objects can be linked in some way,
for example top of one button may be equated to bottom of other.
Afterwards, this relation is maintained automatically by system:
wherewhere second button moved, first will be under it. Many current
systems support constraints in ad hoc manner. For example, Tk's
power to build quickly decent interfaces with pack is essentially
stating (high-level) constraints on widgets. wxWindows' constraints
are simplier and less amazing. What distinguishes Amulet here is
fully generalized constraint support. Constraints can do anything
(even loops are tried to be converged) on anything. Using ad hoc
methods may give some benefits in some cases, for example, for
example, laying out dialog with Amulet constraints is more verbose
than with Tk's packs, but you can do things just not possible with
* Behaviourial interaction model
Contemplating evolution of GUI user-interaction techiques, following
scale may be drawn:
- (back to [your favorite 8-bit box] times) No interaction model
Your code is mess with no obvious destinction with user-event
handling and other code
- MS Windows' message loop
For each large-scaled entity (top-level window) you have "message
procedure" which recieves all events (all they low-level) happening
in that entity. Then you wonder to which lesser part it relates and
act on that, if needed.
- GTK, wxWindows, etc. event handlers, signals, maps, etc.
each user-interactible object has bunch of (relatively low-level) events
which may occur to it. Means to attach handler to needed event is
provided. Handlers are independent and don't put burden on them.
- Amulet's Interactors
No usual graphic Amulet object has ability to interact with user.
Interaction is supported by separate, external subsystem, by
entities called 'Interactors' (of course, that's usual Amulet
objects). Interactors function in high-level event terms, or
behaviours. For example, there interactors for Selecting, Moving,
Growing objects, Text-editing, etc. Low-level events, such as
button- or key-press still handled in unified manner. Amulet widgets
have interactors already attached.
Behaviourial model means that it is very easy and clean to program highly
interactive, direct-manipulation interfaces. E.g.:
// Create an green rectangle
// Cast magic spell upon it:
// "Do Animate!"
// after this, rectangle on screen can be dragged with mouse
Many, many more ;-) Crossplaformedness for X,Win32,Mac is worth
By current standards OpenAmulet has poor widgets set, lacking such
things as trees/outlines, splitpanels, tabbed dialogs, etc.
Latest sources, binaries, samples, language bindings, TODO lists ;-)
available at http://www.openip.org/
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org