On Thu, 2007-07-19 at 12:07 +0100, Claus Reinke wrote:
the idea is well known: build your app as a server, and put an ajax-based gui in front of it, even if server and browser run on the same machine.
A more desktopy alternative: http://www.gtk-server.org/
that looks promising. does that mean one could have the best of both worlds - gtk2hs were available, gtk-server everywhere else? or does this require different code?
It'd certainly requires different code internally to present the same API that Gtk2Hs provides.
even so, it might be worth it to get a single gui framework working with all haskell implementations and all ghc versions.
It would not change the problem with ghc versions. Gtk2Hs does and (almost) always has worked with all versions of GHC, the problem is only the Windows binary builds that are specific to one version of ghc - as are all other binary builds of ghc packages. Using gtk-server would not change that.
or perhaps gtk2hs could offer a bridge to hide any differences between direct and server style code?
That sounds like a lot of work, probably more work than making the current Gtk2Hs code base work with hugs and yhc. And as I say, it would not solve the ghc binary build version issue. One advantage though would be that a GUI api that used gtk-server would not use any FFI and so would not require any header files installed on the target machine so it'd be easier to distribute as source that any end user could build (where as building Gtk2Hs or wxHaskell from source on Windows is non-trivial.) Personally I'd rather spend any effort elsewhere, like binding more of the Gtk+ api, or providing new simple graphics apis on top of Gtk2Hs, or setting up automatic Windows builds so that there are always installers available for all current and recent ghc versions. Duncan