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, Axel.