[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> </DIV>
<DIV><FONT face=3DArial size=3D2>> I had a look at GIO and my first =
impression is=20
that it's interface is nice <BR>> for application writers as well as =
for GUI=20
toolkit implementors. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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> </DIV>
<DIV><FONT face=3DArial size=3D2>> 2. The :=3D =
operator.<BR>> The =3D:=20
function should say "assign to this property". Is seems to be =
the<BR>>=20
wrong way round. Is it possible to use the constructor :=3D , or is =
this<BR>>=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 :-) (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 =3D Attr (w -> IO =
a) (w -> a -> IO ()) -- getter and setter</PRE><PRE>data Prop =
w =3D forall a. (:=3D) (Attr w a) a =
-- :=3D is a constructor</PRE><PRE>set :: w =
-> [Prop w] -> IO ()<BR>set w props<BR> =3D mapM_ setProp =
props<BR> where<BR> setProp ((Attr getter =
setter) :=3D x)<BR> =3D setter w =
x</PRE><PRE>get :: w -> Attr w a -> IO a<BR>get w (Attr getter =
setter)<BR> =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> =3D Attr (\w -> w # =
frameGetTitle)<BR> (\w =
x -> w # frameSetTitle x)</PRE><PRE>...</PRE><PRE>gui =3D do =
...<BR> set frame [title :=3D "hi there"]</PRE>
<DIV><FONT face=3DArial size=3D2> <BR>Really nice!, thanks for =
sparking the=20
idea. Nice application of existential types too.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>> 3. The global mechanism to change =
widgets.=20
<BR>> The set and get functions define a single mechanism to =
modify=20
UI<BR>> components. This seems very neat to me. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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> </DIV>
<DIV><FONT face=3DArial size=3D2>> This is implemented via =
Haskell<BR>>=20
classes. The distribution between functions and classes seem to be =
a<BR>>=20
little ad-hoc, though. The two extremes are probably: a) Define a =
class<BR>>=20
for every function and make each widget which supports this function =
an<BR>>=20
instance of this class. Or b) define a class for every widget and =
make<BR>>=20
every function this widget has a member of this class. Why do you use =
this=20
<BR>> 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. 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 (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> </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 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> </DIV>
<DIV><FONT face=3DArial size=3D2><BR>> 4. Educational vs =
Professional.<BR>>=20
When browsing the drawing primitives, I noticed that you abandon=20
the<BR>> explicit use of Pens (i.e. graphics contexts, GCs). GCs are =
used=20
for<BR>> performance reasons as passing color, thickness etc. each =
time is=20
said to<BR>> be inefficient. This is probably just one example =
begging the=20
general<BR>> question: Are we aiming for an API which is easy to use =
or which=20
enables<BR>> 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> </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> </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> </DIV>
<DIV>All the best,</DIV>
<DIV> Daan.</DIV>
<DIV> <BR>> So far, there is probably more to debate, but I have =
to get=20
some work done <BR>> :-),<BR>> Axel.<BR>> <BR>> <BR>>=20
_______________________________________________<BR>> GUI mailing =
list<BR>>=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>> =
</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>> <BR>> </FONT></DIV></BODY></HTML>
------=_NextPart_000_0019_01C2D160.6B23D050--