-- I have been thinkering with the wxWindows library and made a small Haskell
-- binding to it that just supports this example. It was an interesting exercise
-- since the wxWindows library is a large object-oriented C++ library. (but very
-- portable, well supported, efficient and with lots of super widgets, like an
-- openGL canvas and a HTML renderer)
-- 
-- Anyhow, I think it comes out rather nicely and I am
-- quite surprised how well the wxWindows library lends
-- itself to Haskell access.
-- 
--       Daan.


-----------------------------------------------------------------

main = wxRun $ do 
    w <- wxCreateFrame wxFRAME_DEFAULT_STYLE
    wxSetWindowBackgroundColor w white
    wxSetWindowSize w (Size 100 80)
    wxSetFrameTitle w "Bye!"
    l <- wxCreateLabel w "Hello World"
    wxSetWindowPosition l (Point 10 5)
    b <- wxCreateButton w "Bye"
    wxSetWindowPosition b (Point 10 25)
    wxSetButtonOnCommand b (bye w b l)
    wxShowWindow w where
	bye w b l = do 
	    wxSetControlLabel l "Goodbye"
	    wxSetButtonOnCommand b (wxWindowClose w False)


-- Implementation notes:
--
-- I have only done it for windows yet, both with mingw32 and visual C++.
-- Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while the
-- visual C++ DLL (with the same functionality) was just 640kb :-).
-- 
-- In the end, I couldn't link it directly with a haskell application due to the
-- difference between the C++ and plain C runtimes, so I have made dynamic
-- link library (.dll) of the C++ code. This code exposes a plain C interface (with "extern "C"").
-- This interface is basically a flat C view on the object oriented wxWindows library.
-- 
-- This DLL is accessed with foreign imports from Haskell. Call backs are dynamically
-- created using dynamic exports ("wrapper"). Actually, the hardest part was to
-- make sure that the resource files (.rc) were properly linked in the DLL, as we don't
-- want to deal with those from Haskell.
-- 
-- I don't know yet if this approach also works for unix's (.so files?) or MacOSX,
-- but there probably is a way to do this. In the end, it is good enough if there is
-- some way of wrapping the C++ code into a C library. Maybe someone on this list
-- can tell me more about how this could work on unix like platforms???
-- 
-- The part that is most challenging, and which I am still working on, is trying to fit
-- the event model of wxWindows into a reasonable model for Haskell (or other
-- languages for that matter). Somehow, I need to create "universal" widget objects
-- that are programmable from outside (i.e. Haskell) but normally, one derives application
-- specific objects for each widget in wxWindows. There are mechanisms for more dynamic
-- applications (like I want) but I am still trying to figure out the right way to do it.
-- 
-- I think this is basically a universal problem when trying to interface to foreign object oriented
-- (or any other paradigm for that matter) with a functional language. It is not just the marshalling
-- and calling conventions, but the programming model makes a huge difference. Years ago, when
-- designing H/Direct we automated the marshalling process, but it seems that that is just a small
-- part of the problem. Trying to fit into an entirely different programming model is very hard. For
-- an extreme example, I think that there is no reasonable way of interfacing to the Java Swing model.
-- 
-- Fortunately, it seems that the wxWindows library is much more flexible, and up till now, I haven't
-- encountered any hard problems. Maybe this is actually the right way to go for a Haskell GUI library
-- -- let others do the hard work of maintaining a rich,portable gui library, and we  just have to do
-- the hard work of interfacing to c++ once.
-- 
-- All the best,
--     Daan.
--