I think that we have two alternatives: 1. Design the standard haskell GUI library as a mid-level, IO based library, in wich code would look like the following: win <- newWindow "Hello world" btn <- newButton "Bye" insert win btn onClick btn (close btn) and then design a high-level interface, because the IO based approach uncomfortable. 2. Directly plan the high-level interface, and create backends for it onto the various platforms. In both cases, don't forget that the gtk and gtk2 bindings are in an advanced state, and they already handle signals. I guess that those would be the first two "platforms" onto wich implement the library. Also, remember that both gtk and gtk2 are available on windows, macos, linux and freebsd. Regarding the high-level interface, first of all: it HAS to come. There's no real utility in a language like haskell if mainly used in the IO monad. We have many examples of declarative user interfaces (FRAN appears the to me, but it's just an opinion), and I think that a declarative UI would exploit the power of a declarative language, really speeding up the development of robust applications. Now, stated that it has to come, and considering that the gtk and gtk2 bindings already implement an IO based approach, perhaps the best thing to do would be to design the high level library, with use cases, and work on it until we find a reasonable model. Then we can implement that model on everything we want, qt, gtk, windows, macos etc. Another idea that is always present in my mind: we could also adopt a document model, for example the new standardized XML models that are coming from sun and other major companies cooperation around openoffice. This model could be implemented as an user interface, and would ease printing and cut and paste between different applications. Vincenzo