[Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

John Lato jwlato
Sat Oct 5 22:58:25 UTC 2013


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.

On Oct 4, 2013 7:12 PM, "Alp Mestanogullari" <alpmestan at gmail.com> wrote:
>
> 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.
>
>
> On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY <komadori at gekkou.co.uk> wrote:
>>
>> Dear Alp,
>>
>> Alp Mestanogullari wrote:
>> [snip]
>>
>>> 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.
>>
>> 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:-
>>
>> 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.
>> 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.
>> iii) Proper accessibility is just difficult.
>>
>> 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.
>>
>> Regards,
>>
>> --
>> Robin KAY
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
> --
> Alp Mestanogullari
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131005/ff699783/attachment.htm>



More information about the Haskell-Cafe mailing list