[GUI] I love GIO.

Daan Leijen daanleijen@xs4all.nl
Mon, 10 Feb 2003 23:59:16 +0100


This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C2D160.6B23D050
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Axel,

> I had a look at GIO and my first impression is that it's interface is =
nice=20
> for application writers as well as for GUI toolkit implementors.=20

Thanks! remember though that GIO is heavily influenced by Koen
Claessens Yahu lecture notes.

>  2. The :=3D operator.
>  The =3D: function should say "assign to this property".  Is seems to =
be the
> wrong way round. Is it possible to use the constructor :=3D , or is =
this
> conceptionally difficult?

Great plan. I tried it in my upcoming wxWindows-GIO library, and found
that I needed existential types. Not a problem since we are GHC
dependent anyway :-)  (well, maybe not, NHC is getting really good these =
days).
Anyway, I defined:
data Attr w a  =3D Attr (w -> IO a) (w -> a -> IO ())  -- getter and =
setterdata Prop w    =3D forall a. (:=3D) (Attr w a) a         -- :=3D =
is a constructorset :: w -> [Prop w] -> IO ()set w props  =3D mapM_ =
setProp props  where    setProp ((Attr getter setter) :=3D x)      =3D =
setter w xget :: w -> Attr w a -> IO aget w (Attr getter setter)  =3D =
getter w -- example of an attribute, works for any kind of (wxWindows) =
Frametitle :: Attr (Frame a) Stringtitle  =3D Attr (\w    -> w # =
frameGetTitle)         (\w x  -> w # frameSetTitle x)...gui =3D do ...   =
      set frame [title :=3D "hi there"]=20
Really nice!, thanks for sparking the idea. Nice application of =
existential types too.

> 3. The global mechanism to change widgets.=20
>  The set and get functions define a single mechanism to modify UI
> components. This seems very neat to me.=20

I like that too, makes it all a bit more natural.

> This is implemented via Haskell
> classes. The distribution between functions and classes seem to be a
> little ad-hoc, though. The two extremes are probably: a) Define a =
class
> for every function and make each widget which supports this function =
an
> instance of this class. Or b) define a class for every widget and make
> every function this widget has a member of this class. Why do you use =
this=20
> mixed approach (e.g. class Able, Select, SingleSelect,...)?

Yeah, I don't like it either.  I think that for the new wxWindows =
version I am
going to take an extreme route (especially since I am generating the =
definitions
mostly automatically  (about 256 classes with 2500 methods resulting in =
18000=20
lines of generated haskell marshaling code :-))

I think that the best way would be to add a class for each attribute. =
Something
like:
class AttrTitle w where  title :: Attr w Stringinstance AttrTitle (Frame =
a) where  --every Frame derived object has a title  title =3D ...The =
only problem is that we need again GHC extensions... but  I think that =
most
compilers supports this kind of definition. The good part is that it =
also becomes
easier to define your own kind of controls build from primitive controls =
that are
indistinguishable from the primitive ones (by providing your own =
attribute instances)


> 4. Educational vs Professional.
>  When browsing the drawing primitives, I noticed that you abandon the
> explicit use of Pens (i.e. graphics contexts, GCs). GCs are used for
> performance reasons as passing color, thickness etc. each time is said =
to
> be inefficient. This is probably just one example begging the general
> question: Are we aiming for an API which is easy to use or which =
enables
> professional applications? It's the latter, right?

Regarding the drawing primitives in GIO: I already feel that GIO is too =
heavy-weight
with mutable variables etc. I can't see how to avoid it though. =
Fortunately, the wxWindows
version will get rid of that as almost all the state is stored on the =
wxWindows side.
I think that TkGofer also took advantage of the same kind of thing, =
since Tcl/Tk
stores almost all necessary state.

Regarding the Educational vs Professional: It would be the best if it is =
suitable
for both: that is, it shouldn't be too hard to start with something and =
there should
be some reasonable high-level functions for educational use. However, we =
should
also make sure that the low-level stuff is always available (and rich =
enough).=20
I don't know whether GIO takes the correct approach here... don't forget =
that it
is still just an experimental thing. With the wxWindows library things =
are a bit
easier since one can always use the bare library itself without the =
fancy attributes,
and there is just so much functionality there that everyone can be =
satisfied.

This is btw. on of my main worries for Port. Since it is yet another =
"create our
own library", it may never become rich enough for professional use, or =
may never
even become bug-free or maintained enough. In that sense it would =
'professionally'
be better to build on other people's libraries like GTK, Qt or =
wxWindows.
However, 'educationally', one may be better off using a more =
light-weight approach
like SOEgraphics, or Port.

All the best,
    Daan.
=20
> So far, there is probably more to debate, but I have to get some work =
done=20
> :-),
> Axel.
>=20
>=20
> _______________________________________________
> GUI mailing list
> GUI@haskell.org
> http://www.haskell.org/mailman/listinfo/gui
>=20
> 
------=_NextPart_000_0019_01C2D160.6B23D050
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Dear Axel,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt; I had a look at GIO and my first =
impression is=20
that it's interface is nice <BR>&gt; for application writers as well as =
for GUI=20
toolkit implementors. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks! remember though that GIO is =
heavily=20
influenced by Koen</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Claessens Yahu lecture =
notes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt; &nbsp;2. The :=3D =
operator.<BR>&gt; &nbsp;The =3D:=20
function should say "assign to this property".&nbsp; Is seems to be =
the<BR>&gt;=20
wrong way round. Is it possible to use the constructor :=3D , or is =
this<BR>&gt;=20
conceptionally difficult?<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Great plan. I tried it in my upcoming =
wxWindows-GIO=20
library, and found</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>that I needed existential types. Not a =
problem=20
since we are GHC</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>dependent anyway :-)&nbsp; (well, maybe =
not, NHC is=20
getting really good these days).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anyway, I =
defined:</FONT></DIV><PRE>data Attr w a&nbsp;&nbsp;=3D Attr (w -&gt; IO =
a) (w -&gt; a -&gt; IO ())  -- getter and setter</PRE><PRE>data Prop =
w&nbsp;&nbsp;&nbsp; =3D forall a. (:=3D) (Attr w a) a&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; &nbsp;-- :=3D is a constructor</PRE><PRE>set :: w =
-&gt; [Prop w] -&gt; IO ()<BR>set w props<BR>&nbsp; =3D mapM_ setProp =
props<BR>&nbsp; where<BR>&nbsp;&nbsp;&nbsp; setProp ((Attr getter =
setter) :=3D x)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D setter w =
x</PRE><PRE>get :: w -&gt; Attr w a -&gt; IO a<BR>get w (Attr getter =
setter)<BR>&nbsp; =3D getter w </PRE><PRE>-- example of an attribute, =
works for any kind of (wxWindows) Frame<BR>title :: Attr (Frame a) =
String<BR>title<BR>&nbsp; =3D Attr (\w&nbsp;&nbsp;&nbsp; -&gt; w # =
frameGetTitle)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (\w =
x&nbsp; -&gt; w # frameSetTitle x)</PRE><PRE>...</PRE><PRE>gui =3D do =
...<BR>         set frame [title :=3D "hi there"]</PRE>
<DIV><FONT face=3DArial size=3D2>&nbsp;<BR>Really nice!, thanks for =
sparking the=20
idea. Nice application of existential types too.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt; 3. The global mechanism to change =
widgets.=20
<BR>&gt; &nbsp;The set and get functions define a single mechanism to =
modify=20
UI<BR>&gt; components. This seems very neat to me. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I like that too, makes it all a bit =
more=20
natural.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt; This is implemented via =
Haskell<BR>&gt;=20
classes. The distribution between functions and classes seem to be =
a<BR>&gt;=20
little ad-hoc, though. The two extremes are probably: a) Define a =
class<BR>&gt;=20
for every function and make each widget which supports this function =
an<BR>&gt;=20
instance of this class. Or b) define a class for every widget and =
make<BR>&gt;=20
every function this widget has a member of this class. Why do you use =
this=20
<BR>&gt; mixed approach (e.g. class Able, Select,=20
SingleSelect,...)?<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Yeah, I don't like it either.&nbsp; I =
think that=20
for the new wxWindows version I am</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>going to take an extreme route =
(especially since I=20
am generating the definitions</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mostly automatically&nbsp; (about 256 =
classes with=20
2500 methods resulting in 18000 </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>lines of generated haskell marshaling =
code=20
:-))</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I think that the best way would be to =
add a class=20
for each attribute. Something</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>like:</FONT></DIV><PRE>class AttrTitle =
w where<BR>  title :: Attr w String</PRE><PRE>instance AttrTitle (Frame =
a) where  --every Frame derived object has a title<BR>  title =3D =
...<BR></PRE>
<DIV><FONT face=3DArial size=3D2>The only problem is that we need again =
GHC=20
extensions... but&nbsp; I think that most</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>compilers supports this kind of =
definition. The=20
good part is that it also becomes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>easier to define your own kind of =
controls build=20
from primitive controls that are</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>indistinguishable from the primitive =
ones (by=20
providing your own attribute instances)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR>&gt; 4. Educational vs =
Professional.<BR>&gt;=20
&nbsp;When browsing the drawing primitives, I noticed that you abandon=20
the<BR>&gt; explicit use of Pens (i.e. graphics contexts, GCs). GCs are =
used=20
for<BR>&gt; performance reasons as passing color, thickness etc. each =
time is=20
said to<BR>&gt; be inefficient. This is probably just one example =
begging the=20
general<BR>&gt; question: Are we aiming for an API which is easy to use =
or which=20
enables<BR>&gt; professional applications? It's the latter, =
right?<BR></DIV>
<DIV>Regarding the drawing primitives in GIO: I already feel that GIO is =
too=20
heavy-weight</DIV>
<DIV>with mutable variables etc. I can't see how to avoid it though.=20
Fortunately, the wxWindows</DIV>
<DIV>version will get rid of that as almost all the state is stored on =
the=20
wxWindows side.</DIV>
<DIV>I think that TkGofer also took advantage of the same kind of thing, =
since=20
Tcl/Tk</DIV>
<DIV>stores almost all necessary state.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regarding the Educational vs Professional: It would be the best if =
it is=20
suitable</DIV>
<DIV>for both: that is, it shouldn't be too hard to start with something =
and=20
there should</DIV>
<DIV>be some reasonable high-level functions for educational use. =
However, we=20
should</DIV>
<DIV>also make sure that the low-level stuff is always available (and =
rich=20
enough). </DIV>
<DIV>I don't know whether GIO takes the correct approach here... don't =
forget=20
that it</DIV>
<DIV>is still just an experimental thing. With the wxWindows library =
things are=20
a bit</DIV>
<DIV>easier since one can always use the bare library itself without the =
fancy=20
attributes,</DIV>
<DIV>and there is just so much functionality there that everyone can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This is btw. on of my main worries for Port. Since it is yet =
another=20
"create our</DIV>
<DIV>own library", it may never become rich enough for professional use, =
or may=20
never</DIV>
<DIV>even become bug-free or maintained enough. In that sense it would=20
'professionally'</DIV>
<DIV>be better to build on other people's libraries like GTK, Qt or=20
wxWindows.</DIV>
<DIV>However, 'educationally', one may be better off using a more =
light-weight=20
approach</DIV>
<DIV>like SOEgraphics, or Port.</DIV>
<DIV>&nbsp;</DIV>
<DIV>All the best,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Daan.</DIV>
<DIV>&nbsp;<BR>&gt; So far, there is probably more to debate, but I have =
to get=20
some work done <BR>&gt; :-),<BR>&gt; Axel.<BR>&gt; <BR>&gt; <BR>&gt;=20
_______________________________________________<BR>&gt; GUI mailing =
list<BR>&gt;=20
</FONT><A href=3D"mailto:GUI@haskell.org"><FONT face=3DArial=20
size=3D2>GUI@haskell.org</FONT></A><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><A=20
href=3D"http://www.haskell.org/mailman/listinfo/gui"><FONT face=3DArial=20
size=3D2>http://www.haskell.org/mailman/listinfo/gui</FONT></A><BR><FONT =

face=3DArial size=3D2>&gt; <BR>&gt; </FONT></DIV></BODY></HTML>

------=_NextPart_000_0019_01C2D160.6B23D050--