For all interested in Haskell GUIs, there is now a second preview release of qtHaskell - a set of Haskell bindings for Trolltech's Qt available at http://qthaskell.berlios.de There are a number of important changes from the previous version. 1. All FFI pointers are now Foreign Pointers. Those of a type derived from QObject are wrapped as QPointer types and only this wrapper is deleted when their finalizer runs. All other types are automatically deleted by their finalizer when they go out of Haskell scope - or more precisely when the finalizer acutally runs. To make the actual deletion time more easily controlable, most example code uses the function "returnGC" instead of just "return" in callback functions. Also non QObject derived types can be constructed with an alternative constructor qSomeObject_nf which has no finalizer. In this case it's the programmers job to delete the object when required. 2. All Qt enumerated types are implemented as equivalent Haskell types instead of just being of type Int as before. In fact I'v used separate types for enumerated types and their corresponding "flags" types in Qt. For example enum Qt::AlignmentFlag flags Qt::Alignment have equivalent qHaskell types: data CQt__AlignmentFlag a = CQt__AlignmentFlag a type Qt__AlignmentFlag = QEnum(CQt__AlignmentFlag Int) data CQt__Alignment a = CQt__Alignment a type Qt__Alignment = QFlags(CQt__Alignment Int) and a corresponding set of value functions i.e. qt__AlignLeft and qtf__AlignLeft qt__AlignRight and qtf__AlignRight ... The correct value function must be used depending on the parameter type of the api function being called e.g. buttonBox <- qDialogButtonBox1 (qDialogButtonBoxf__Ok + qDialogButtonBoxf__Cancel) for a "flags" type in "widgets.hs", or slider <- qSlider1 qt__Vertical for an "enum" type in "hellogl.hs" 3. All qtHaskell functions which correspond to some overloaded Qt api function use a final numeral in their name which corresponds to the number of parameters in the function. For example: QRect () QRect ( const QPoint & topLeft, const QPoint & bottomRight ) QRect ( const QPoint & topLeft, const QSize & size ) QRect ( int x, int y, int width, int height ) becomes qRect qRect2 qRect4 where qRect2 is a class of functions that can take either QPoint or QSize for their second parameter. This nomeclature has the advantage of being compatible beteen different Qt versions and of making it possible for the qtHaskell programmer to tell what the name of the corresponding qtHaskell function is just by looking at the Qt documentation. N.B. although qtHaskell 1.1.1 programs are not therefore forwards compatible with qtHaskell 1.1.2, only minimal editing is required to upgrade them. 4. The Haskell api code is now split into separate modules for each Qt class. All these modules are exposed in the qtc package, hence by explicitly importing only the required modules for an application, the size of the corresponding executable can be kept to a reasonable size. All example qtHaskell programs have a corresponding program prefixed with "cs", which has only this explicit importing, e.g. "widgets" and "cswidgets". Some example programs have also a corresponding "as" prefixed program which uses explicit module importing and also uses Arthur Widgets, about which see below. 5. There are two new detailed examples, csterrainsim and csPathDeform. csterrainim, is an eventloop based realtime terrain simulator based on OpenGL and has a frame rate almost the same as its C++ original. csPathDeform, is a vector graphic demo program based on a timer interrupt, which uses Qt's Arthur Widgets. Arthur Widgets demos are implemented by Qt as a derived style class ArthurStyle and a generic frame class ArthurFrame, from which the actual demo program frames are derived. Both ArthurStyle and ArthurFrame are replicated in Haskell in the qtHaskell library and used by csPathDeform in an entirely analagous manner to that of the original Qt C++ "deform" demo program. This demonstrates that qtHaskell can be used to build generic objects/interfaces etc, derived from the basic Qt classes just as in C++. Also, use of the ArthurStyle class means that the callback functions are more resource intensive. The implementation of handlers in qtHaskell has been revised for this release, and the csPathDeform has a smoothness and responsiveness that is virtually indistinguishable from the C++ original. Enjoy! David Harley -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/