delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/10/28/14:15:47

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Thu, 28 Oct 1999 21:16:39 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N 4B0B2C85
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <19886.991028@is.lg.ua>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: [ANN] OpenAmulet 4.3
Mime-Version: 1.0

Hello,

  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 ;-)

http://www.openip.org/

  To be more informative, some kind of blurb (somewhat lengthy and
advocatic, sorry):

=============
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
intercation model.

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
  update.
  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
  Tk.

* 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
  Am_Object r=Am_Rectangle.Create().Set(Am_FILL_STYLE,Am_Green);
  // Cast magic spell upon it:
  // "Do Animate!"
  r.Add_Part(Am_Move_Grow_Interactor().Create())
  // after this, rectangle on screen can be dragged with mouse

What's more?
----------

Many, many more ;-) Crossplaformedness for X,Win32,Mac is worth
immediate note.

What's not?
-----------

By current standards OpenAmulet has poor widgets set, lacking such
things as trees/outlines, splitpanels, tabbed dialogs, etc.

Where?
------
Latest sources, binaries, samples, language bindings, TODO lists ;-)
available at http://www.openip.org/


=============

Best regards,
 Paul                          mailto:paul-ml AT is DOT lg DOT ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019