<div dir="ltr">If these said libraries let us write a good API on top, then perfect! The problem is to actually pick the ones fulfilling our needs I think, all the major candidatures have pretty serious drawbacks, AFAIK.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY <span dir="ltr">&lt;<a href="mailto:komadori@gekkou.co.uk" target="_blank">komadori@gekkou.co.uk</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Alp,<br>
<br>
Alp Mestanogullari wrote:<br>
[snip]<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn&#39;t be the API, but really what library we use underneath so that it&#39;s cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this.<br>


</blockquote></div>
Herein lies, for my purposes, the downfall of attempts to build GUI tool-kits on top of a blank canvas. From the perspective of binding to the platform, getting the basic functionality of a cross-platform GLUT or SDL equivalent isn&#39;t terribly difficult. You can layer your own widget system on top but even if you don&#39;t care about native look and feel (and I don&#39;t particularly), there are still three big functionality hurdles in my mind to building serious applications:-<br>


<br>
i) Proper text rendering is more difficult than placing one glyph after another on a line. You need to bind to each platform&#39;s text rendering engine: Pango/others, Uniscribe, and Core Text.<br>
ii) Proper text input is more difficult than listening for key press and release events. You need to bind to the each platform&#39;s input method system: XIM/IBus/others, IMM, and NSTextInputClient.<br>
iii) Proper accessibility is just difficult.<br>
<br>
There are plenty of applications where that doesn&#39;t matter and there are lots of attractive things about a pure Haskell implementation with beautiful high-level API. However, from my perspective, there are also attractions to outsourcing as much of that work as possible to existing libraries on the other side of the FFI even though that seems to bring us down to lower-level.<br>


<br>
Regards,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Robin KAY</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Alp Mestanogullari
</div>