[GUI] Re: Know you backends

[Krasimir Angelov]

> 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