That is a good question. Personally, I would have preferred to see a GTK port of the low-level layer of Clean This would also allow us to work together with the Clean people, they have an excellent compiler and lots of experience with GUI's, and it could foster more exchange of knowledge between both communities.
Maybe Krasimir can tell us more about the issues involved?
The first big stone which I was found was handling of scollbars in the windows. The scrollbars are implemented rather different in Windows and GTK. Under Windows the application must explicitly specify the exact scrollbar position in response to WM_VSCROLL and WM_HSCROLL messages. Under GTK the position are handled from GtkScrolledWindow and the application receives notifications after each change in horizontal or vertical position. Under GTK the scrollbars are automaticaly shown/hidden when the view domain becomes great/less than window size. Under Windows this requires explicit manipulation with scrollers. In the ObjectIO library this is realized with WindowHScroll/WindowVScroll attribute and value of type ScrollFunction. The ScrollFunction calculates new position of the scrollbar after each scroll event. That means that scrollbar manipulation is handled at top level instead of low level C code. I was tried to change library but I found that this reflects in too many places. For example each time when some control is resized then the view domain required for all controls is changed and this may reflect the scrollers. I think that it isn't imposible to improve the library but this was too discounraged for me. There was also some minor reasons anticipate from Daan:
For example, the generation of identifiers (openId) is quit unsafe. In the Haskell tradition we would use a monadic bind to name widgets. ie.
w <- window []
instead of
w <- openId openWindow ... [ WindowId w, ...]
Other things are the widget attributes that are specified using constructors. A more Haskellish style would use function names instead of constructors (as to be able to abstract from them) and use type classes for grouping them (as to prevent using illegal attributes on a certain widget). i.e.
w <- window [title =: "My window" ]
instead of
w <- openId openWindow ... [ WindowId w, WindowTitle w...]
I was thinking about this disadvantages about two months before to found the first reason. However this is not too important. I also don't like openId. What should happen if I forgot w is an Id window and use it again as Id for some control. The library has some validation routines and probably will found this as runtime error while I like to catch this error in compilation time. For that reason I was thinking about how to found some work around but I don't know any decision which are easy to implement in existing ObjectIO. The implementation of attributes is other disadvantage but I think that it is easy to replace them with functions and classes. The original HToolkit package uses list of values of type "Conf w" where w is the type of widget. The Conf is just function of type "w -> IO ()". This design was adopted from FranTk and solves trouble with attributes. To avoid openId I use some tricks. The window form is defined like function which takes as arguments variables which represent controls inside the form. In the same time the controls are defined in the same function. I use fixIO function and lazy evaluation to take result of function as its argument. There is also another trouble with OS layer in ObjectIO. Because the Clean FFI doesn't allow C functions to execute Clean the OS layer is implemented with two co-threads. The first thread is in the C world and is synchronized with Clean thread with mutexes. The C<->Haskell communication can be much more easy but the ObjectIO still uses old fashion comunication with threads. Avoidance of this trouble isn't so easy because large part of library depends on co-threads. This is avoided in both HToolkit and Port. Best regards, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com