From: Peter M. <pet...@gm...> - 2006-01-17 07:46:05
|
There's a request on the Gtk2Hs development page for "[h]elp with further work on a medium-level API", and the author of the _Libraries and Tools for Haskell_ page (http://www.haskell.org/libraries/) complains that, "[t]here is a need for a supported medium-level GUI library." I'm curious about this. What do these people mean by "medium-level API"? Why do we need one? Why not just build straight up to a Fudgets-like layer? Are there any examples out there that somebody could show me? Please note that this is not an offer of assistance: I'm still little more than a Haskell apprentice. Cheers, Peter McArthur. P.S. Despite Duncan Coutts' kind support, I *still* haven't managed to get the Haddock docs to link properly. Maybe this sample error message will inspire somebody? Warning: Graphics.UI.Gtk.TreeList.IconView: the following names could not be resolved: IO Maybe Int FunPtr Ptr Bool SelectionMultiple SelectionSingle OrientationVertical CInt |
From: Axel S. <A....@ke...> - 2006-01-17 09:20:57
|
On Tue, 2006-01-17 at 07:45 +0000, Peter McArthur wrote: > There's a request on the Gtk2Hs development page for "[h]elp with > further work on a medium-level API", and the author of the _Libraries > and Tools for Haskell_ page (http://www.haskell.org/libraries/) > complains that, "[t]here is a need for a supported medium-level GUI > library." > > I'm curious about this. What do these people mean by "medium-level > API"? Why do we need one? Why not just build straight up to a > Fudgets-like layer? Are there any examples out there that somebody > could show me? There was a long discussion two years ago about a "Common GUI API" for Haskell and what it should entail. We settled for not building such a library since there was not enough interest; that is why we now have the situation that there are at least two competing libraries: wxHaskell and Gtk2Hs (probably also TkHaskell, but the rest of the ~30 libraries is not maintained anymore). During that discussion we argued what should be in a Common GUI API. We made the following distinction: - low level API: wrapper around the bare library functions - medium level API: some convenience functions that make life easier - high level API: a purely functional framework The low level API is what Gtk2Hs mostly is. The Attributes add-on is already medium level API since it makes code look much cleaner and more concise, so in fact, we are not really keen on getting a new medium level API, we will just work on the Attribute stuff a bit more. The reason why we do not advocate a high-level API is that nobody really knows how such an API should look like. I've worked with Fudgets a long time ago and found that it was a pain once you get beyond the Hello- World problem. FranTk probably has similar problems. The reason for these problems are not only that all high-level APIs are rather incomplete, but also that they have conceptual problems. There are many practical problems that one simply can't solve. We had other proposals for a high-level API based on Arrows, which we welcome. But these certainly will not replace the low- and medium-level APIs that Gtk2Hs provides right now, since those are the only layers that expose the full functionality of the underlying Gtk toolkit. > Please note that this is not an offer of assistance: I'm still little > more than a Haskell apprentice. Fair enough. We've given up on building the Common GUI API, too. I don't think programming with the Attribute lists is too bad. It's actually quite convenient. Axel. > P.S. Despite Duncan Coutts' kind support, I *still* haven't managed to > get the Haddock docs to link properly. Maybe this sample error > message will inspire somebody? > > Warning: Graphics.UI.Gtk.TreeList.IconView: the following names could > not be resolved: > IO Maybe Int FunPtr Ptr Bool SelectionMultiple SelectionSingle > OrientationVertical CInt I hope we can sort this out in the ./configure script. Note that some of the names in there are part of Gtk and that this warning also indicates that the documentation is not quite ironed out. |
From: Gour <li...@at...> - 2006-01-17 10:40:38
|
On Tue, 2006-01-17 at 09:18 +0000, Axel Simon wrote: > The low level API is what Gtk2Hs mostly is. The Attributes add-on is > already medium level API since it makes code look much cleaner and more > concise, so in fact, we are not really keen on getting a new medium > level API, we will just work on the Attribute stuff a bit more.=20 [snip] > But these certainly will not replace the low- and medium-level APIs > that Gtk2Hs provides right now, since those are the only layers that > expose the full functionality of the underlying Gtk toolkit. =46rom by newbie perspective, the present API which gtk2hs provides is very much high-level API in comparison with the plain C api - it's simple matter of using Haskell over C. Moreover, it looks like new Treeview API, make it even more powerful, hopefully enough for gui-layer :-) Sincerely, Gour |