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/
_______________________________________________
Haskell mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
