Good morning, 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. What appeals to me (having a low-level GUI binding, gtk2hs) is that binding to such an API is actually worthwhile (i.e. it's more than just renaming functions). Some questions, comments and critics about GIO: 1. Using IO (). All functions use the IO () monad unlike the proposed port of Object IO which introduces GUI (). I think this decision is the Right Thing (tm). (If other libraries insist of having their own Monad then it can become impossible to mix these two libraries.) 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? 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. 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,...)? 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? So far, there is probably more to debate, but I have to get some work done :-), Axel.