Dear all,

I would like to elaborate on a number of things that have been said 
recently about Object I/O (be it in Clean or Haskell). Object I/O has been 
designed to be platform independent: it is separated into two layers: one 
OS dependent layer and one abstract Clean/Haskell layer built on the lower 
layer. The OS dependent layer has been implemented for the MS Windows 
platform and we are currently working on a Mac port. Krasimir Angelov has 
tried to port it to GTK, and says that the OS dependent layer apparantly 
still has an OS bias that makes it less suitable for GTK. He mentions the 
following differences:

[Krasimir Angelov at: 02:21 20-1-03 -0800]
>    * The GTK cannot draw rotated text and rotated
>elipses. This depend on restrictions imposed from X
>server.
>    * The Win32 backed lack powerful text formating
>features like these given from PANGO.
>    * The Font families given in the GTK and Win32 are
>rather different. The font management are still
>similar on each platform.
* Graphics features will always differ on all platforms. Object I/O 
anticipates on this by offering an open-ended graphics API. Type classes 
for drawing and filling (Drawables and Fillables respectively) are defined 
as well as a limited set of standard instances (lines, curves, rectangles, 
text). To extend the graphics capabilities one can simply create a new 
module in which these new instances are declared and implemented. This has 
for instance been done to extend the graphics library with the ability to 
render bitmaps.

* I don't see why one would need these text formatting features in this 
context. Perhaps Krasimir can explain this?

* Font family naming conventions already depend on the particular set of 
installed fonts on a machine. A decent program can therefore never assume 
the existence of whatever font, and it should try to find out this 
information via the OS.

I would certainly not be surprised if the OS dependent layer of Object I/O 
indeed has an OS bias, but the above points don't seem to be problematic to 
me. Please note that I have no experience with Gtk. However, for an old 
version of Object I/O we have had a Master Thesis project porting it 
successfully to X Windows (using the OpenLook toolkit). My guess is that 
Gtk is inspired by the X Windows approach. Again, Krasimir can elaborate on 
this.

One big advantage of a two-layered approach is that applications can have a 
native look-and-feel. Although I am perfectly aware of the burden of 
keeping ports up-to-date, I think it is very important that applications 
written in the "standard" GUI library for Clean/Haskell behave as others. 
People (even scientists) do get annoyed when confronted with applications 
that do not conform to the normal behaviour. The two-layered approach also 
does not exclude a port to a platform indepent toolkit, so that might serve 
as a starting point. Finally, a well-documented and well-defined OS 
dependent layer will ease the development of high-level GUI libraries. 
Researchers will not need to re-invent the wheel and see the result of 
their implementation effort more quickly.

[Axel Simon at: 14:45 23-1-03 +0000]
>Dialogs in Windows are specified in dialog units, i.e. they scale with the
>font size but cannot be resized by the user: scrap Gtk's dynamic sizing
>capability.  Buttons on Aqua cannot have icons in them, scrap icons in Gtk
>and Windows button. Scrap Aquas hierarchical view in several columns
>(could be simulated if Windows supports adding columns on the fly, Gtk
>would), scrap additional columns next to a hierarchical tree since Windows
>doesn't support that. Scrap Window's concept of groups in dialog and
>keyboard accelerators in general since Aqua doesn't know about hotkeys.
>AFAIK a lot of UI elements on Windows which are considered "standard" are
>implemented in the Microsoft Foundation Classes. Thus to actually use
>these, one has to use the MFC written in C++ (or .net).
This has partially been answered by Krasimir. In addition, I would say that 
the answer to these differences is abstraction. As an example, consider 
resizing of controls. In Object I/O, a control can have a resize attribute 
that defines its size in terms of the size of (one of) its parent(s). When 
put in a resizeable parent object that is resized, it will resize according 
to its attribute. If the platform does not allow resizeable 
dialogs/windows, then that is no problem. Similar to icons in buttons: add 
an attribute to specify the icon in a button and if the platform does not 
support it, you don't show it. No scrapping needed; good set of attributes 
and semantics needed.

[Sengan.Baring-Gould at: 13:21 22-1-03 -0700]
>While programming at the IO level works, it does not give one
>much of an advantage versus programming in C, in sharp contrast
>to most other Haskell programming.
>
>The diversity of high level solutions which differ totally in
>outlook ("express the widget as a datastructure" versus
>"everything is a composition of functions") gives the impression
>that the library designers never used their toolkits in larger
>applications which would have made any rough edges painfully obvious.
>It seems therefore that a lot more work needs to go into this field
>before we know what a good high level Functional GUI toolkit looks like.
>Contrast this with more mature fields such as pretty printing,
>parsing, etc where there are many solutions all following the same
>ideas.
I don't agree with the "does not give one much of an advantage versus 
programming in C". Many proposals have been written that make use of the 
elaborate type system of functional languages to glue correct GUI programs; 
many approaches use functional language features do construct well-typed 
and well-structured Domain Specific Languages.

"...the library designers never used their toolkits in larger 
applications..." True: I didn't, but other people have. Check out the 
CleanIDE (by Diederik van Arkel):
http://www.cs.kun.nl/~clean/About_Clean/body_the_clean_ide/body_the_clean_ide.htm
and the beautiful Sparkle Proof Tool (by Maarten de Mol):
http://www.cs.kun.nl/~maartenm/Sparkle/


Regards,
Peter