I have a haskell + fltk app. However, the route I took was to write the gui in c++, and then write an API to talk to it in C (just a set of 15 or so very short functions), and then FFI that API into haskell. I also have a C wrapper for Fl::run(), fork off my various haskell threads and then the main one calls Fl::wait() in a loop. Other threads can ship 'Fltk a' values (just a newtype for 'IO a' actually) to the main thread via a function that drops the action in an MVar and then calls Fl::awake() to break the wait(), which then runs the action and goes back to wait().
Events go back to haskell via a queue on the fltk side that's read from by another API function on an event handler thread that drops it into a TChan, which is merged with several other TChans which is what the main event loop (in haskell) reads from. The main event loop pulls something out of the TChans and does whatever, which might wind up calling API functions which get shipped over to the Fl::wait() thread as above. Actually, the the event loop is pure and actions are run outside of it by diffing before and after states, but anyway. I wasn't sure if it would work, but it seems to be pretty ok so far. It's not very fast if there are 100s of events coming in per second, but for low bandwidth like mouse drags it's fine. There are also some occasional performance hiccups but I haven't put any effort into tracking those down yet. In theory if I track down a latency issue that I can't solve in haskell for whatever reason, I can just push it down into c++ and expose it via the API. Anyway, I tried this approach because I like the idea of a narrow API between the GUI and the rest of the program. In theory if I ever didn't like fltk I could swap out something else, but mostly it lets me write the low level GUI stuff in c++ without lots of painful FFI wrapping. Maybe it would work for your app? _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
