<p dir="ltr">I think you've misunderstood Robin's point. The problem is that each of these libraries is platform-specific. Writing an api on top of one is work enough, but writing a cross-platform api that binds to the appropriate platform-specific backend is a major undertaking. </p>
<p dir="ltr">On Oct 4, 2013 7:12 PM, "Alp Mestanogullari" <<a href="mailto:alpmestan@gmail.com">alpmestan@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
><br>
> On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY <<a href="mailto:komadori@gekkou.co.uk">komadori@gekkou.co.uk</a>> wrote:<br>
>><br>
>> Dear Alp,<br>
>><br>
>> Alp Mestanogullari wrote:<br>
>> [snip]<br>
>><br>
>>> I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it'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>
>><br>
>> 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't terribly difficult. You can layer your own widget system on top but even if you don't care about native look and feel (and I don'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'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'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'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,<br>
>><br>
>> -- <br>
>> Robin KAY<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
><br>
><br>
> -- <br>
> Alp Mestanogullari<br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
</p>