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 setterdata Prop w = forall a. (:=) (Attr w a) a -- := is a constructorset :: w -> [Prop w] -> IO ()set w props = mapM_ setProp props where setProp ((Attr getter setter) := x) = setter w xget :: w -> Attr w a -> IO aget w (Attr getter setter) = getter w -- example of an attribute, works for any kind of (wxWindows) Frametitle :: Attr (Frame a) Stringtitle = 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 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)
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.
So far, there is probably more to debate, but I have to get some work done :-), Axel.
_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui