[GUI] I love GIO.

Axel Simon A.Simon@ukc.ac.uk
Tue, 11 Feb 2003 21:57:51 +0000

On Mon, Feb 10, 2003 at 11:59:16PM +0100, Daan Leijen wrote:
> 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).
Hm, ok then I see a good reason not to use := . I think it's better to 
stick to Haskell 98 features. But I don't feel very strongly about this. 
If := is going to be a reserved symbol one day, then we should perhaps not 
use it.

So you're now doing a binding to wxWindows. May I criticise?!

wxWindows tries to give a native look by using the native API. It seems to 
do a good job. But when it comes to native feel, I wonder if this 
full-fledged API can abstract away the semantic differences of the 
platforms. I guess there is always need for a serious application to 
implement certain bits of the GUI directly with the native API to bridge 
this semantic gap. Can you use wxWindows for the standard GUI stuff and 
still use the native API for some functionality? If yes, then this is what 
- I think - we are aiming for. In that case I might consider dumping my 
gtk2hs binding and help you with a binding to wxWindows.

> > 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 Stringinstance 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)
Why not the other extreme route: Having one class for each widget? The 
name overlap is minimal I think and it is much easier to understand.

> > 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.
If let wxWindows handle the applications state (via StablePtr), how are 
you going to make that type safe? Mulit-parameter classes? I think 
the common GUI API should be in Haskell 98.

> 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.
I think we should go for a purely professional API. You can always put a 
simple layer on to of it, but not vice versa. Using colors and fonts 
directly and avoiding graphics contexts is wrong IMHO.

> > So far, there is probably more to debate, but I have to get some work done 
> > :-),
One point that came up in our Departmental FP group was that the way 
Object I/O identifies objects is superior to GIOs. They create an 
identifier with a special monadic function rId. The you construct an 
algebraic data type which specifies you GUI. GIO on the otherhand uses 
functions to create widgets. You use these widgets values to pass them to 
other widgets (e.g. containers). Note that in both settings it is possible 
to put one button into two different container. But only in the Object I/O 
approach this can easily be detected (you keep all created rIds in an 
array and see if they have been used yet). In GIO you would need to 
traverse the whole widget tree of all windows to determine if a button is 
already inserted somewhere else.

So much for now,