[GUI] Re: Know you backends

[Peter Achten]

At 06:52 30-1-03 -0800, Krasimir Angelov wrote:
> > 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.
>[..]
>... 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 think that it isn't imposible to improve
>the library but this was too discounraged for me.
The reason for the complicated implementation of scrollbars is that they 
have to be handled explicitly by the programmer on the Mac platform. The 
impression that I get from your account is that scrollbar handling on GTK 
is rather similar to Windows.
In general, one really needs a ScrollFunction to determine its behaviour: 
imagine a textprocessor that allows you to handle text with different font 
(heights). Then scrolling down/up one line depends on the height of the 
current top/bottom line.
I can't blaim you for being discouraged... the implementation of the Object 
I/O library isn't as 'clean' is I would like it to be.

>[..]  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.
The co-thread architecture is indeed a major bottleneck both in 
understanding the implementation, and performance (which BTW is already 
very good). The reason is, as Krasimir says, the historical lack of calling 
Clean from C. Fortunately, this has been incorporated recently to Clean by 
John van Groningen, so this gives us a good opportunity to get rid of this 
approach and adopt a more natural and intuitive implementation. This will 
give another performance boost to the library.

Regards,
Peter