Current version : 1.0.1, information on previous versions can be found here.
Release date : April, 21st 1998

General

• The <OPStorage> and <OPCarbonCopy> classes have been modified in order to handle properly automatic type conversions (e.g. from <OPValue> to another type and vice-versa).
• A new <OPaC_TypeInfo> internal class has been added in order to collect and publish information about the basic OPaC data types. This data is made available through the new <OPTypeInfo> class.
• A new <OPBitsetInfo> class has been added to represent bitsets.
• The base class <GetPublicData> methods have been changed to return the type information as instances of <OPTypeInfo>. This provides a simpler and more coherent interface (also modified for class <OPDataMirror>).
• The <OP_TARGET_ARG> macro has been expanded and a third argument is now required. It is used as a description of the argument.
• The <DELETE_ARRAY> and <DELETE_ARRAY_FROM_ZONE> macros correctly free the memory, even with compilers which allocate an additional counter at the beginning of an array (the counter is used by <operator delete[]>). Beware
  to use these macros only with structs/classes which have a <vtbl> (because of a virtual member, embedded object, etc.) !
• The <OPList> and <OPHashTable> classes have been extended. Class <OPList> now supports a rudimentary cache.
• The format of the archives has been slightly modified: the archive files now have a 32-byte header containing an archive identifier, represented by the string "OPaC-BIN" followed by 8 zeroes and the text "binary archive" padded with 2 zeroes.
• The <OPStorage> class treats objects tagged with "AutomaticObject" in a special way (the attribute must be a dictionnary); the dictionary is stored in place of the object. When restoring, the dictionary's contents will be interpreted as following: "Type"=="Type:Path", "Root"=>root and "Path"=>path used to retrieve the object thanks to OPQueryData with the specified root and path.
• The <operator ->> of <OPObjectRef> (and all other references) now calls the <CheckAndResolve> method, so that the object gets an opportunity to replace the <OPObjectRef> pointer by another object's (useful for the mirroring classes).
• The methods <Resolve> and <CheckAndResolve> have been added to the base reference class and to the base class too.
• The storage class now supports internal purging when storing objects.
• The missing class <OPDictIterator> has been added.
• A new class <OPDicTree> can be used to represent arborescent dictionary like structures (kind of registry).
• The look manager now reads its defaults from an initialisation file (a kind of "policy" file or registry).

User Interface

• The class <OPObjectWell> has been extended and provides a "new" button. Furthermore, it always accepts dropping.
• The class <OPWindow> has been extended in order to handle modal dialogs and windows.
• The class <OPTabView> has been reparented. The parent class <OPMultiView> provides some of the functions formerly implemented in <OPTabView>.
• A new class <OPStepView> has been added, so that step-by-step wizards can easily be implemented.
• The class <OPDragView> supports the "EmbeddedObjectForDrag" attribute on its view, so that abstract objects can be dragged and dropped in a more user friendly way.
• Buttons support translucid background colors.

Interface Builder

• The IB uses dynamic message passing to find out if an object has to be initialised further after cloning.
• The IB provides an improved "New" function for the views, which allows dynamic instanciation and initialisation of complex widgets, based on a step-by-step wizard

Systen Dependent (Win32 & Linux)

• The complete graphical abstraction layer has been reimplemented based on the "grafix" library in order to support alpha transparency and translucency.
• The font engine relies on the FreeType implementation.
• The color manager is now 100% system independent (since an internal true color model is supposed).
• The Font Manager is now system independent. The only parameters which are needed for its initialisation are directory paths and file names. This is not yet fully implemented.

Linux

• The current implementation of sd_grailwdo.cxx is very slow. It is based only on the <XDrawPoint> primitive, which is unacceptable for raster-ops. This will have to be implemented more seriously soon.
• Documentation about porting is now included in the source distribution. It may be somewhat out of date with respect to the graphic engine.