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