[Haskell] ANNOUNCE: qtHaskell 1.1.2, the second preview version of qtHaskell

[David Harley]

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/