Hi Luc
when experimenting with wxHaskell, I was considering some basic gui builders, like glade, http://glade.gnome.org/, or even the youger http://wxglade.sourceforge.net, that I just discovered.
wxGlade looks quite promising ! (it's almost visual basic :-)
these generate either code via xml ressources files, that the code generators read and produce code in the language you fancy ( in c++, eiffel, perl, python..).
I was considering giving a try for the wxHaskell binding, and was interested in hearing some feedback on that idea ...
As the XML that you will load dynamically is 'untyped', you need to somehow emit a typed haskell file together with the XML to load this data safely into Haskell. That would mean that you either need to extend wxGlade or that you write a typed interpreter for the XML data in Haskell itself.
well, I expresed myself badly. I did not thought first about dynamically loading an XML file. rather using the xml file that glade produce to store the interface description, and produce the code out of it, statically. that was the approach we follwoed in the eiffel community. glade produce a xml file, then eglade is called, that reads it and produce the "gui" part of your application. all you have to do is insert the function call from widget actions..
-- Daan.
btw. I am personally not a big believer of gui interface builders, especially not with the "layout" combinators that you can make in Haskell -- I think that writing the layout with combinators is faster for an expert than building it in a GUI.
Well, combinators are great. and if you can automate their generation in a visual manner, that's even more intuitve. for beginners, to start with. for gui learner, to learn the library combinators.. for professional, to accelerate the gui building... from a methaphore viewpoint, the glade thingy just help you build visually your composite widget tree, serialized in XML, then HAglade would read it and produce the code, a syntax tree that match the widget tree in fact. ie XML -> (Abstract syntax) tree -> code. a matter of strategy, in fact... ;-) Luc