--- Wolfgang Thaller
So I'm still in favour of platform-specific backends; but I wouldn't protest too much if we opted for the Wx option after some more discussion.
I continue to think that a library which supports platform-specific backends will be much more flexible. The HToolkit is designed from high-level to low-level. First I deside which functionality I like to have at high-level and after that I deside which primitive operations are required at low-level. After that all low-level primitives can be implemented for each backend. We can use wxWindows as backend for our first prototype. The main advantage of wxWindows is that it is well designed and have good portability. Anyhow if we deside to support low-level platform independent API then this will allow for someone to write other backends. One of things which I like in the HToolkit is that it is very thin layer over the platform specific GUI. The wxWindows contains many classes which are not intended for GUI: - generic classes - wxArray, wxArrayString, wxHashMap wxHashTable, wxScopedArray, wxScopedPtr, wxString - threads - wxThread, wxMutex, wxSemaphore, wxMutexLocker ... - database management - wxDb, wxDbTable, wxDbColDef ... - about 10 classes - wxInputStream, wxOutputStream, wxFile ... - about 20 classes - other We already have useful and functional replacements for these features. The corresponding classes will remain unused. Probably this is true also for Eiffel, Python and many other languages which uses wxWindows (except C++). The wxHaskell project uses only GUI part of wxWindows. The binding is made with wrapper functions written in C. The wrapper plays the same role as low-level C API in the HToolkit. My proposal is to get agreement on this API. The common API will allow to merge low-level parts of HToolkit and wxHaskell and then we can support both Windows, GTK/GNOME and wxWindows. Cheers Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com