Re: [Haskell-cafe] Pure functional GUI
Another way to get glade on Windows is to download mono, which contains both gtk and glade. One advantage of getting it this way is you then have mono at your disposal for benchmarking ghc ;-) (Not that you'd benchmark a gui app, but it seems there are many people who still think that comparing haskell with non-gc'd imperative languages having a corruptable stack/heap, such as C, is meaningfull ;-) ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
2007/8/9, Peter Verswyvelen <[EMAIL PROTECTED]>: > Yeah I tried that one, but only the runtime, because I assumed that glade > would be part of it, but I could not find it. I guess I should install the > development version. Windows users look differently at these things, they > expect all tools to be precompiled ;) I'll try again and dig deeper. Runtime is enough.. But Glade is packaged separetly. http://gladewin32.sourceforge.net/modules/wfdownloads/viewcat.php?cid=2 I just cheked it and it works flawlessly (as far as my 1 minute test goes ;) ) (Oh. I seem to remember that I needed GTK runtime from THIS page. It didn't go nicely with runtime installed with "GIMP for windows" package.) Have fun, Radek -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
Radosław Grzanka wrote: The google knows?? http://gladewin32.sourceforge.net/modules/news/ Ah - most optimal... Now finally I can try Glade. :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pure functional GUI
Yeah I tried that one, but only the runtime, because I assumed that glade would be part of it, but I could not find it. I guess I should install the development version. Windows users look differently at these things, they expect all tools to be precompiled ;) I'll try again and dig deeper. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Radoslaw Grzanka Sent: Thursday, August 09, 2007 10:22 PM To: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] Pure functional GUI 2007/8/9, Peter Verswyvelen <[EMAIL PROTECTED]>: > > Indeed - the *hard* part seems to be figuring out how to run Glade on > Windoze... > > I did not dare to ask this question because I could not believe this was > hard... So anybody know how to do this? Run Glade on Window$? The google knows?? http://gladewin32.sourceforge.net/modules/news/ Frankly, I'm using Linux now, and even under windows (I must use it at work) I use vmware with ubuntu.. But not so long ago I ran glade on windows using stuff from this page. HTH, Radek. -- Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
2007/8/9, Peter Verswyvelen <[EMAIL PROTECTED]>: > > Indeed - the *hard* part seems to be figuring out how to run Glade on > Windoze... > > I did not dare to ask this question because I could not believe this was > hard... So anybody know how to do this? Run Glade on Window$? The google knows?? http://gladewin32.sourceforge.net/modules/news/ Frankly, I'm using Linux now, and even under windows (I must use it at work) I use vmware with ubuntu.. But not so long ago I ran glade on windows using stuff from this page. HTH, Radek. -- Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pure functional GUI
> Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... I did not dare to ask this question because I could not believe this was hard... So anybody know how to do this? Run Glade on Window$? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin Sent: Thursday, August 09, 2007 7:31 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Pure functional GUI Duncan Coutts wrote: > On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: > >> uestion on using gtk from haskell: how easy is it to integrate >> with glade? ie, can we directly bind glade form elements to haskell >> variables? How easy is it to bind events to glade form elements from >> within Haskell? >> > > It's pretty easy, see the Gtk2Hs/Glade tutorial: > > http://haskell.org/gtk2hs/docs/tutorial/glade/ > Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
Duncan Coutts wrote: On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: uestion on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: > To be fair, GTK is pretty standard. This is so even for "big name" > gc'd imperative languages such as C#. Sure, you can use Windows.Forms > in C#, but you often wouldnt, because of the patent burden. > Also, gtk in partnership with glade rocks! > > How easy is gtk to use from haskell by the way? In gc'd imperative > languages, typically only one thread is allowed to communicate with > the GUI, and you need to set up a whole bunch of message-parsing stuff > to communicate with other threads. To what extent is this easier in > Haskell? The story on this isn't as nice as it could be. It depends on which GHC runtime system you choose to use. In the single threaded rts, you can use threads willy nilly as they all run in the context of one OS thread (though it requires a little bit of code to set up cooperative scheduling). In the fully threaded rts you have to be very careful to only use GUI stuff from a single OS thread. Gtk2Hs provides a couple functions to post actions to the main GUI thread. We've been thinking of ways to make this more transparent but it's not so easy. > Other question on using gtk from haskell: how easy is it to integrate > with glade? ie, can we directly bind glade form elements to haskell > variables? How easy is it to bind events to glade form elements from > within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
On 8/9/07, Marc Weber <[EMAIL PROTECTED]> wrote: > > -- load up the glade file > dialogXmlM <- xmlNew "simple.glade" > let dialogXml = case dialogXmlM of >(Just dialogXml) -> dialogXml >Nothing -> error "can't find the glade file \"simple.glade\" > \ > \in the current directory" > > -- get a handle on a couple widgets from the glade file > window <- xmlGetWidget dialogXml castToWindow "window1" > button <- xmlGetWidget dialogXml castToButton "button1" > Oooo... nice :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
>Other question on using gtk from haskell: how easy is it to integrate >with glade? ie, can we directly bind glade form elements to haskell >variables? How easy is it to bind events to glade form elements from >within Haskell? Download the source and have a look at the demo/glade folder.. ;-) (I've pasted the most important lines below) Marc [...] -- load up the glade file dialogXmlM <- xmlNew "simple.glade" let dialogXml = case dialogXmlM of (Just dialogXml) -> dialogXml Nothing -> error "can't find the glade file \"simple.glade\" \ \in the current directory" -- get a handle on a couple widgets from the glade file window <- xmlGetWidget dialogXml castToWindow "window1" button <- xmlGetWidget dialogXml castToButton "button1" [...] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
To be fair, GTK is pretty standard. This is so even for "big name" gc'd imperative languages such as C#. Sure, you can use Windows.Forms in C#, but you often wouldnt, because of the patent burden. Also, gtk in partnership with glade rocks! How easy is gtk to use from haskell by the way? In gc'd imperative languages, typically only one thread is allowed to communicate with the GUI, and you need to set up a whole bunch of message-parsing stuff to communicate with other threads. To what extent is this easier in Haskell? Other question on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was "a regressive view of support for imperativeprogramming in Haskell")
FranTk, Haggis, Fudgets, Object I/O for Haskell, Gadgets, Pictures, HTk, Haskell Tk, HToolkit, Gtk+HS, Gtk2Hs, wxHaskell, FunctionalForms, .. and no, that list is not exhaustive by any means (you can find abstracts for some of these in old haskell community reports, but a lot of functional gui lib research pre-dates those reports). functional gui libs used to be one of the favourite haskell research excercises. some of those were low-level bindings, some were high-level declarative abstractions, but that wasn't the problem. the problem was that very nearly all of them came and went. the declared goal of the current generation was to provide more long-lived platforms, leaving most of the maintenance to others by binding directly to popular imperative libraries. it was always the intention that someone would build higher-level declarative approaches on top of those bindings. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
On Wed, Aug 08, 2007 at 08:22:41PM +, Peter Verswyvelen wrote: > Well, if you want to make it as big as QT, yes. > > But even just a simple purely functionaly GUI framework that is part of the > library would be nice, because right now it gives the impression it cannot be > done in Haskell... Perhaps the yi keybaard mapping library can be seen as ui ? At least everything is written in haskell, parsing keyboard events and displaying reactions.. I will never compete with gtk etc though. I think this might be an example that it can be done in haskell Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was "a regressive view of support for imperativeprogramming in Haskell")
On Aug 8, 2007, at 3:14 PM, Peter Verswyvelen wrote: So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library. I had quite a lot of experience in pure functional GUI technology in developing the user-interface for the ICAD system -- a domain specific language for mechanical engineering. We developed another domain specific language for describing user-interface objects as a tree structure and implemented commands as applicative transactions using Zippers, though we called them path transactions. (Oh, did I mention this was in 1987?) Redisplay and undo of course were handled automatically. It was developed on Lisp Machines and then ported to X-Windows. I believe there are some nooks and crannies in the aircraft industry were it is still being used. There were some issues which time may have solved. 1.) Redisplay could be a little tedious due to slow video hardware. 2.) Locality became a problem with the shared data-structures being spread throughout memory. Thus performance could be adversely affected by paging. (In 1987, 8MBytes of Lisp Machine memory cost $10,000.) Issues that time won't solve. 1.) It was non-standard -- at the time that meant "not Motif." Does anybody remember Motif? 2.) It is a thankless task. Innovation is not welcomed. It's better left up to committees. I don't believe that there is any technical reason why something interesting couldn't be done. But if you actually want people to use your GUI tools, that is several orders of magnitude more work -- and not the most interesting kind. An interesting possibility that arises when coding has become so effortless as it now has in Haskell, is to create GUI technologies just for a single project. Encourage innovation and experimentation in usability with a captive audience. An example of this is the PureData computer music system. The user-interface is quite innovative and non-standard, but the users of the application have taken it to a cult status even though it's purposefully kind of ugly. http://puredata.info/ ___ (---o---o-o-o---o-o-o( David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
Well, if you want to make it as big as QT, yes. But even just a simple purely functionaly GUI framework that is part of the library would be nice, because right now it gives the impression it cannot be done in Haskell... E.g. Concurrent Clean seems to have a simple UI library. >- Oorspronkelijk bericht - >Van: Duncan Coutts [mailto:[EMAIL PROTECTED] >Verzonden: woensdag, augustus 8, 2007 09:36 PM >Aan: 'Peter Verswyvelen' >CC: 'Donn Cave', haskell-cafe@haskell.org >Onderwerp: re: [Haskell-cafe] Pure functional GUI (was "a regressive view of >support for imperativeprogramming in Haskell") > >On Wed, 2007-08-08 at 19:14 +, Peter Verswyvelen wrote: > >> So could you please tell me more about the problem with pure >> functional GUIs and why this is not part of the Haskell library? I >> mean a GUI library completely written in Haskell, not wrapping a >> popular library. > >Partly because just getting the drawing and interaction behaviour to be >acceptable would be many person-years of work. > >GUI toolkits are not especially simple things. Even if you could do it >in just 1/10th of the number of lines of code of Gtk+ or Qt it'd be a >massive undertaking. > >Duncan > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
re: [Haskell-cafe] Pure functional GUI (was "a regressive view of support for imperativeprogramming in Haskell")
On Wed, 2007-08-08 at 19:14 +, Peter Verswyvelen wrote: > So could you please tell me more about the problem with pure > functional GUIs and why this is not part of the Haskell library? I > mean a GUI library completely written in Haskell, not wrapping a > popular library. Partly because just getting the drawing and interaction behaviour to be acceptable would be many person-years of work. GUI toolkits are not especially simple things. Even if you could do it in just 1/10th of the number of lines of code of Gtk+ or Qt it'd be a massive undertaking. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
re: [Haskell-cafe] Pure functional GUI (was "a regressive view of support for imperativeprogramming in Haskell")
As a newbie (okay I will not write this again, you all know I'm a newbie by now ;-), I don't understood what the problem of a pure functional GUI is. To me, having an imperative background, a graphical application is just a big tree of data that evolves when events from the OS come in. (this data is NOT per se the data for the GUI element; instead use the model-view-controller design pattern) In Haskell, instead of mutating the data (as done in C/C++), a infinite stream of this tree-data is generated responding to an infinite steam of events, as in Paul's SOE book (the reactive stuff). Since most of the data can be shared, the performance impact should be minimal. So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library. Thanks, Peter >- Oorspronkelijk bericht - >Van: Donn Cave [mailto:[EMAIL PROTECTED] >Verzonden: woensdag, augustus 8, 2007 08:56 PM >Aan: haskell-cafe@haskell.org >Onderwerp: Re: [Haskell-cafe] a regressive view of support for imperative >programming in Haskell > >On Wed, 8 Aug 2007, Paul Hudak wrote: >... >> Well, you could argue, monad syntax is what really made Haskell become >> more accepted by the masses, and you may be right (although perhaps >> Simon's extraordinary performance at OSCOM is more of what we need). On >> the other hand, if we give imperative programmers the tools to do all >> the things they are used to doing in C++, then we will be depriving them >> of the joys of programming in the Functional Way. How many times have >> we seen responses to newbie posts along the lines of, "That's how you'd >> do it in C++, but in Haskell here's a better way...". > >It seems to me that Brian Hulley threw the glove down hard. Does >pure functional Haskell offer a better way to write a GUI? > >I love the functional stuff myself, but if real applications depend >on extensive imperative logic, we're best served by a language that >cheerfully embraces the inevitable and handles it well. Monads, the >do syntax, whatever it takes (I have a soft spot for O'Haskell, but >alas I must be nearly alone on that.) Hopefully, it's still better, >and not at all irreconcilable with the Functional Way. > > Donn Cave, [EMAIL PROTECTED] > >(That's a genuine question, by the way - my attempt to build a >current Haskell GUI library on NetBSD foundered and I have no >experience with Haskell GUI coding, but it's on the list of things >I would like to look at. So if there's one that really illustrates >the virtues of pure functional Haskell programming, that would be >a welcome tip!) > >___ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
