[GUI] Proposal Proposal: haskell-gui addendum to haskell standard

Fri, 24 Jan 2003 11:48:32 +0100

--=====================_9409557==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

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

--=====================_9409557==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
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] 
<blockquote type=cite cite>&nbsp;&nbsp; * The GTK cannot draw rotated
text and rotated 
elipses. This depend on restrictions imposed from X 
server. 
&nbsp;&nbsp; * The Win32 backed lack powerful text formating 
features like these given from PANGO. 
&nbsp;&nbsp; * The Font families given in the GTK and Win32 are 
rather different. The font management are still 
similar on each platform.</blockquote>
<dl>
<dd>* 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.

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

<dd>* 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.

</dl>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 &quot;standard&quot; 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] 
<blockquote type=cite cite>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.&nbsp; 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
&quot;standard&quot; are 
implemented in the Microsoft Foundation Classes. Thus to actually use
 
these, one has to use the MFC written in C++ (or .net).</blockquote>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] 
<blockquote type=cite cite>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 (&quot;express the widget as a datastructure&quot; versus 
&quot;everything is a composition of functions&quot;) 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.</blockquote>I don't agree with the &quot;does not give one much of
an advantage versus programming in C&quot;. 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. 
 
&quot;...the library designers never used their toolkits in larger
applications...&quot; True: I didn't, but other people have. Check out
the CleanIDE (by Diederik van Arkel): 
<a href="http://www.cs.kun.nl/~clean/About_Clean/body_the_clean_ide/body_the_clean_ide.htm" eudora="autourl">http://www.cs.kun.nl/~clean/About_Clean/body_the_clean_ide/body_the_clean_ide.htm</a> 
and the beautiful Sparkle Proof Tool (by Maarten de Mol): 
<a href="http://www.cs.kun.nl/~maartenm/Sparkle/" eudora="autourl">http://www.cs.kun.nl/~maartenm/Sparkle/</a> 
 
 
Regards, 
Peter 
</html>

--=====================_9409557==_.ALT--