gui libs? no thanks, i'm just browsing.. ;-)
gui libs are wonderful, but haskell sometimes has too few and sometimes has too many. and those we have do not work with every haskell implementation. and when they do work (usually with ghc, these days), they need to be rebuilt whenever ghc is updated, even if the gui lib hasn't changed at all (one gui lib binding per ghc version). still, we put up with that when we need all those gui lib features, because we have to, and we're happy to live in one of those periods when there are such bindings to full-featured gui libraries. but what about quick and dirty/cheap and cheerful graphics? over the years, HGL/SOEGraphics has served as a persistent reminder that things keep changing, and that when they do, something breaks. even if all people want to do is draw some simple graphics, or animations. i don't have a solution, but i'd like to throw another alternative into the ring, based on the ongoing fight between web browsers and other guis for world dominance.. 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. attached is a silly quick&dirty demo of some of the relevant concepts, including a fake haskell http-server, an html/canvas/httprequest/ javascript-based gui, and some simple graphics/buttons/text. tested on windows, with opera 9.01 and ghc 6.6.1. it will probably not work with other browsers, but it should work with opera on other platforms, or with other haskell implementations supporting Network. (you might have to hardcode the file name at the top of the source if not using ghc; to make it work with other browsers, you need workarounds for standard browser incompatibilities) to run, load Canvas.hs into ghci and call main. then start up opera, and visit 'http://localhost:8000/start' (to change that port number, change both 'main' in the haskell source, and 'get' in the html source). that should yield an html page with further instructions. have a look, and please let me know if it works on your os/ haskell implementation, and what you think about the idea. i won't do it myself, but perhaps someone could code up SOEGraphics based on this?-) and if not, this might still help out some of you who need simple low-overhead guis (things can get hairy very quickly if you need more than simple guis)? some of you might have to fight through implementing browser- based guis for their day jobs anyhow, but may want to put haskell behind those guis; or you might find haskell prototyping an easier sell, if the gui can be reused for the "real" implementation.. claus further reading/download: Opera browser (windows, macos, solaris, linux, ..) http://www.opera.com/download/ html 5 -- working draft, june 2007 (3.14.11 canvas element) http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas tutorial http://developer.mozilla.org/en/docs/Canvas_tutorial http://developer.mozilla.org/en/docs/Drawing_Graphics_with_Canvas
On Thu, 2007-07-19 at 00:12 +0100, Claus Reinke wrote:
gui libs are wonderful, but haskell sometimes has too few and sometimes has too many. and those we have do not work with every haskell implementation. and when they do work (usually with ghc, these days), they need to be rebuilt whenever ghc is updated, even if the gui lib hasn't changed at all (one gui lib binding per ghc version). still, we put up with that when we need all those gui lib features, because we have to, and we're happy to live in one of those periods when there are such bindings to full-featured gui libraries.
You're right, that's annoying. It's particularly a problem for Windows GHC users who expect pre-built binaries, since GHC currently requires all libs to be rebuilt with each new minor GHC version. It's particularly annoying for GUI libs which are non-trivial to build from source (due to needing so many C header files and such) and so there is always a lag between when GHC gets updated and when someone (me) gets round to making a new binary build for Windows. Our hope is that we can get Gtk2Hs working with Yhc some day. That'd be interesting because it shouldn't have the same versionitis issues and the same compiled GUI program should run unaltered on Windows, Linux or OSX (and several others).
but what about quick and dirty/cheap and cheerful graphics? over the years, HGL/SOEGraphics has served as a persistent reminder that things keep changing, and that when they do, something breaks. even if all people want to do is draw some simple graphics, or animations.
There's a SOEGraphics implementation with Gtk2Hs, but then of course see problem 1. :-)
i don't have a solution, but i'd like to throw another alternative into the ring, based on the ongoing fight between web browsers and other guis for world dominance..
[..] Sounds fun! :-) Duncan
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. Simon
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version.
Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you.
it may indeed "only" be major versions, but that is troublesome enough. at one point, i had the then current 6.4.2, the upcoming 6.6, and head, and then there are of course those "heads up" mails for head, suggesting rebuilds of all libraries.. i was using wxhaskell instead of gtk2hs, but that had the same issues (even worse when there was no maintainer, as ghc moved on, there were no lib binaries for new ghc versions, and any existing lib binaries for old ghc versions were useless..). abi compatibility would be very nice to have (if the library/binding code doesn't change, newer ghc major versions should still be able to link to bindings compiled with older ones). that is only going to become more important as fewer libraries are going to be shipped with ghc itself now (also with dynamically linked libraries). is there even tool support for "i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version."? claus
On Thu, 2007-07-19 at 12:02 +0100, Claus Reinke wrote:
is there even tool support for "i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version."?
Gentoo has such a tool. The ghc ebuild instructs users to run ghc-updater after upgrading ghc. It identifies all ghc library packages that portage installed for all other versions of ghc and re-emerges them in the correct order (possibly upgrading them at the same time). It'd probably be a useful feature to include in cabal-install. Duncan
is there even tool support for "i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version."?
We will have soon. The nix distribution system will be able to do exactly this. You pass a ghc compiler for each build description. Passing another and reinstalling a package will cause all dependencies to be rebuild as well. I'm working on this. I'v already around 100 packages installed from hackage. (But no gui lib yet) I hope that this all will work at least to be able to test within the following 2 weeks. (But things may change) Marc
| abi compatibility would be very nice to have (if the library/binding | code | doesn't change, newer ghc major versions should still be able to link | to | bindings compiled with older ones). that is only going to become more | important as fewer libraries are going to be shipped with ghc itself | now | (also with dynamically linked libraries). That is all true. ABI compatibility would be nice. But I don't see how to combine with GHC's other goals. Notably, we frequently add new information to interface files, and it would be a major constraint not to be able to do so. For the present at any rate, ABI incompatibility between major releases seems like the lesser evil. Simon
That is all true. ABI compatibility would be nice. But I don't see how to combine with GHC's other goals. Notably, we frequently add new information to interface files, and it would be a major constraint not to be able to do so.
that is the bit i never quite understood: if newer formats just add information, that should be no problem. the problem, presumably, comes when newer ghcs can no longer manage without that extra information. so, if ghc was truly upgraded (add things, improve things) instead of modified (add some, take away some), then it should be able to work with "old" compiled libs at least as well as its previous version would have. just that it could do even better if it was allowed to recompile the old lib itself.. what am i missing? claus
I'm not sure if you're talking about C++ ABIs or C ABIs? If you're already using a C ABI, and you're getting incompatibilities, well I have nothing useful to say :-) If you're talking about C++ ABIs, technically it's possible to use a Generator to drop-down into a C ABI, pump across the interface at a C level, function by function, then wrap back into C++ classes. The advantage is that you decouple the classes on either side of the interface, so it's possible to add new methods to the classes without breaking anything. (Warning: I have no idea to what extent what I just wrote relates to ghc etc. I did make a generator to cross a C++ ABI boundary before, to link an msvc C++ dll with a mingw C++ exe: http://spring.clan-sy.com/phpbb/viewtopic.php?t=7991 )
On Thu, 2007-07-19 at 10:06 +0100, Simon Peyton-Jones wrote:
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version.
Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you.
Yes, I've always been confused by that. You go to some effort to not change the binary format of .hi files or change the ABI of the RTS etc and yet ghc explicitly checks that the .hi files are exactly the same version preventing any mixing anyway: Foo.hs: module Foo where foo = 3 Bar.hs module Bar where import Foo bar = foo + foo $ ghc-6.6 -c Foo.hs $ ghc-6.6.1 -c Bar.hs Bar.hs:3:0: Bad interface file: Foo.hi mismatched interface file versions: expected 6061, found 6060 So yes, that's why the Gtk2Hs 0.9.11 Windows installer checks for exactly ghc-6.6 and not 6.6.x in general. Duncan
On Thu, 2007-07-19 at 13:01 +0100, Duncan Coutts wrote:
On Thu, 2007-07-19 at 10:06 +0100, Simon Peyton-Jones wrote:
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version.
Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you.
Yes, I've always been confused by that. You go to some effort to not change the binary format of .hi files or change the ABI of the RTS etc and yet ghc explicitly checks that the .hi files are exactly the same version preventing any mixing anyway:
This is where you go in and hack the version, but I'll shut up now.
Hi Claus Ising ghc-6.6 and Opera 9.20 i thought that everything would work until I tried the page in Firefox 2.0.0.1 Opera: Those maroon rectangles in all four corners appear, alse the text x/y: ... is shown when clicking. But the drawing doesn't appear, does'n show any errors within the Error Console either. In Firefox (2.0.0.3) Firebug does show the JS error: evt has no properties clicked()start (line 63) onclick(click clientX=0, clientY=0)start (line 1) addLabel(evt.clientX,evt.clientY) But the drawing ( |_| rotating clockwise) appears. Clicking has no effect If you don't know it yet mootools is a really nice JS framework providing transition suppert etc. Perhaps this might be useful somehow as well. Marc
as Marc pointed out, there was a problem with my javascript use that showed up as an event error in firefox. Miguel has suggested how to remove that issue. i've also added commands to set the colour explicitly, and to move to the origin after translation, so that firefox now draws whole squares, rather than leaving out the first line. having just upgraded my opera (so much smaller and easier than full gui libs;-), the modified code appears to work with opera (9.22) and firefox (1.5.0.6), on windows, using ghc 6.6.1. to avoid spamming this list, i've put the updated code and a couple of screenshots online at: http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/browsing/ please note that this code is not at all pretty, but is meant to show most of the necessary pieces. if you want to use the idea seriously, the haskell code would need cleaning up, the html/javascript would need checking for standard compliance (there are several standards involved, so it is tempting to code by modifying examples, which are not always correct, even if they work on some browser). you might also want to consider using one of the many javascript/ ajax browser gui frameworks, if only to isolate you from browser incompatibilities. but even if you code to a single standard-compliant browser, your clients might find it easier to download and install that than a full gui-lib binding. hth, claus
On 7/19/07, Claus Reinke
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/ martin
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? even so, it might be worth it to get a single gui framework working with all haskell implementations and all ghc versions. or perhaps gtk2hs could offer a bridge to hide any differences between direct and server style code? claus
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
participants (7)
-
Claus Reinke -
Derek Elkins -
Duncan Coutts -
Hugh Perkins -
Marc Weber -
Martin DeMello -
Simon Peyton-Jones