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