[erlang-questions] My quest for a decent way to make a GUI in erlang

Albin Stigö <>
Wed Jul 26 22:20:23 CEST 2017


Hi Joe,

Nice research! Interesting list of software.

I've used a lot of GUI libraries. My favorite is Cocoa/Xcode and QT is
pretty good too.

I like interface builders because you get instant visual feedback.
Also IMHO the tricky part is not the initial layout of widgets but how
to handle resizing. Interface builder in Xcode solves this with
constraints. They have a learning curve but it works pretty well. For
serious work you also have to consider i18n.

Cocoa is good because you can build interfaces both programmatically
and with interface builder, and you can combine the two approaches.
Interface builder just serializes the object graph so they are
essentially the same.

I'd also say that a binding mechanism is essential to avoiding a lot
of boilerplate code to keep the GUI updated. Cocoa has bindings (on
osx) that's based on key value observing on (ios and osx). QT has
signals and slots.


--Albin


On Wed, Jul 26, 2017 at 7:45 PM, Joe Armstrong <> wrote:
> More on my search for a good (understandable) GUI engine...
>
> I've spent the last few weeks botanising through various
> GUI/graphics construction kits - and goodness what a mess.
>
> I thought I'd share some of my experiences and see if
> it resonates with anybody.
>
> 1) Gui building is an (almost) total mess - I say almost because
>    there is some good software around - but the good stuff tends to be
>    experimental, undocumented and difficult to use.
>
> 2) The most popular frameworks are bloated, difficult to use and
>    impossible to understand without significant effort.
>
> 3) wxWidgets and the Erlang port wxErlang is usable - but the
>    documentation assumes you are familiar with the wxWidgets way
>    of doing things and with OO callback programming - which is
>    *very* Un-Erlang way of thinking
>
> 4) The use of interface builders (Xcode, etc.) is a symptom of
>    problem. GUI codes gets so messy that it is virtually impossible
>    to write "by hand" - so enter the GUI builder - this is basically
>    giving up on the idea that GUIs can be written in a clear and
>    simple manner by hand.
>
> 5) In the late 1970 - mid 80's there were several GUI languages
>    and systems that were easy to use and easy to program. For
>    example Smalltalk, TCL, Visual basic, Borland Turbo Graphics
>
> Is there any good stuff around today?
>
> Surprisingly the answer is yes - but the code is difficult to find
> not supported and not mainstream.
>
> First a couple of papers that you might find interesting:
>
>    + http://www.eugenkiss.com/projects/thesis.pdf
>      and https://github.com/eugenkiss/7guis/wiki
>
>     The author solves 7 different problems with a number of different
>     GUI's
>
>    + http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/
>
>    A great read - This blog has a lot of good information about the techniques
>    used to build several state of the art GUIs (for example Reaper,
> Blender, Light table)
>    so If you've every wondered how fancy GUIs work this article gives
> several clues.
>
>    It also has the rather nice example of a GUI written using the
> Electron Framework
>    that made an 189 MB executable to bang up a window with a small number of
>    controls in it.
>
>    There's a list of references in one of the comments to this blog that
>    lead to several interesting *small'ish GUIs'
>
> Good stuff
>
>    I did find some good software and some potentially very good software.
>    My top picks are as follows:
>
>    http://inscore.sourceforge.net/
>
>       This is my favorite from an architectural POV.
>       It is controlled entirely by sending it messages.
>       Not a single callback to be seen
>
>    https://github.com/andlabs/libui
>
>       This looks very promising - it's a cross platform adaption layer
>       with a C interface - I've only build it on a Mac but
>       the adaption layer looks pretty easy to use. There's a C interface
>       that could be adapted to Erlang.
>
>       There are very few examples
> https://github.com/andlabs/ui/wiki/Getting-Started
>       has a go example - but if you download and build the system the
>       C examples are easy to follow.
>
>    http://www.red-lang.org/
>
>       Is amazing - Red is a language inspired by REBOL.
>
>       REBOL never achieved much popularity - perhaps Red will.
>       Once you've see red you'll wonder why you program in anything else
>       (there are good reasons - but for simply desktop apps Red is great).
>
>    https://github.com/wjakob/nanogui
>
>       Restores my faith in programming - it's small and built on top
>       of https://github.com/memononen/NanoVG
>
>       NanoVG is basically a canvas type interface to OpenGL
>
>       Reading the NanoGui code made me wonder if the best way to make
>       a GUI for erlang would be to use OpenGL for the low-level stuff
>       and do all the rest in Erlang.
>
>       Buttons etc. are pretty easy to define as processes which I believe
>       is the way http://www.wings3d.com/ did things.
>
> The future
>
> I'm still undecided - one of more of the following seem attractive
>
>     1) wxErlang - it works *but* it's big and ugly and has a nasty
>        programming model
>     2) An interface to Red would be great - but red is pretty unknown
>     3) libui looks promising - anybody interested in this?
>     4) the nanogui/NanoVG track looks good - anything with nano in the
>        name has my vote
>     5) The inscore architecture rules - NO CALLBACKS - Yea
>
> Verily verily I say unto you - "useth not the callback, even though
> they that useth the callback are ignited with a great passion and
> extol the virtues of the callback - for therein lies the madness
> that do come when the callback faileth for reasons not comprehended'
>
> Thus it is writ.
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions


More information about the erlang-questions mailing list