<br><br><div class="gmail_quote">On Sat, Mar 21, 2009 at 1:30 PM, Michael Mossey <span dir="ltr">&lt;<a href="mailto:mpm@alumni.caltech.edu">mpm@alumni.caltech.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I can imagine that GUI programming is no easier (yet). It is inherently very &quot;stateful.&quot; GUI&#39;s have modes, such as which screens are displayed, which dialogs are displayed, which options within those dialogs are valid given the other state of the program, etc. When I write GUIs, I often diagram them as state machines to get a handle on what&#39;s going on.</blockquote>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So, I&#39;m not familiar with GUI programming on Haskell, but would you say the statefulness of GUIs (in their typical implementations) is the reason they are no easier on Haskell?</blockquote>
<div><br></div><div>Even if you want to see GUIs as state machines, it is perfectly possible to make pure stateful GUIs in Haskell without using IO. </div><div><br></div><div>I guess the problem is that a purely functional GUI library - be it stateful or continuous- is only useful if it comes with lots of GUI controls, and writing all these controls is a big task. It is much easier to wrap an existing C toolkit to get the job done, even if it means making your hands dirty :-) Furthermore modern GUI toolkits like perform real time animation, styling, data binding, layout, etc... so this is a huge undertaking.</div>
<div><br></div><div>That being said, I think many many Haskellers really would love to use a purely functional GUI toolkit, but unfortunately, a production quality toolkit does not exist yet. I guess building all controls needed for a GUI library could be a global community effort if we all agreed on a good FRP (=functional reactive programming) library to build the GUI on, but currently no clear winner exists.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I strongly prefer to use qtHaskell because I&#39;m familiar with Qt, and Qt is extremely capable. For example, it can draw text and shapes with antialiasing, which will be great for a music score editor. Music scores have lots of small shapes to fit on the screen, and antialiasing will provide ease of reading. I don&#39;t know how much of Qt is implemented in qtHaskell, or whether the latest version of Qt (4.4) is implemented.</blockquote>
<div><br></div><div>Cairo - part of GTK - can also do that, but I expect it to be slower than Qt (at least on Windows)</div><div><br></div><div>My personal opinion: GUIs don&#39;t really &quot;work&quot; either in imperative or functional programming. But we can make it work in the imperative world because we can hack around the problems.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks,<br>
Mike<div><div></div><div class="h5"></div></div></blockquote><div> </div></div>