Dear Axel,
> I had a look at GIO and my first impression is
that it's interface is nice
> for application writers as well as for GUI
toolkit implementors.
Thanks! remember though that GIO is heavily
influenced by Koen
Claessens Yahu lecture notes.
> 2. The := operator.
> The =:
function should say "assign to this property". Is seems to be the
>
wrong way round. Is it possible to use the constructor := , 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 = Attr (w -> IO a) (w -> a -> IO ()) -- getter and setter
data Prop w = forall a. (:=) (Attr w a) a -- := is a constructor
set :: w -> [Prop w] -> IO ()
set w props
= mapM_ setProp props
where
setProp ((Attr getter setter) := x)
= setter w x
get :: w -> Attr w a -> IO a
get w (Attr getter setter)
= getter w
-- example of an attribute, works for any kind of (wxWindows) Frame
title :: Attr (Frame a) String
title
= Attr (\w -> w # frameGetTitle)
(\w x -> w # frameSetTitle x)
...
gui = do ...
set frame [title := "hi there"]
Really nice!, thanks for sparking the
idea. Nice application of existential types too.
> 3. The global mechanism to change widgets.
> The set and get functions define a single mechanism to modify
UI
> components. This seems very neat to me.
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
> 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
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 String
instance AttrTitle (Frame a) where --every Frame derived object has a title
title = ...
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).
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.