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

Thu Jul 27 02:45:57 CEST 2017

I think NeXT and OpenStep used display postscript? Cocoa evolved from
NeXT but they moved away from display postscript for performance
reasons. A lot has happened since then so maybe the time has come for
display postscript?

> ...a minimal system with only
> the good parts (which in my mind is *just* a drawing surface, can a canvas
> or SVG responsive widget) a small scripting language (say Lua or JS) and
> a communication method (say JSON) and transport mechanism (say TCP)

Sounds a bit like X11. But X11 isn't exactly minimal of course.
Interestingly there's a shift away from this model with Mir and
Wayland. From my understanding this is to make better use of modern
graphics hardware; shaders etc.

A canvas model is really great for graphics experiments. If someone
could port something like Processing.org to Erlang, that would be
really neat. But for applications I do like a native look and feel.

--Albin

On Wed, Jul 26, 2017 at 10:57 PM, Joe Armstrong <erlang@REDACTED> wrote:
> One other point that I omitted to make
>
> When I wrote ex11 (a graphics experiment) I realised that
> 3D objects with behaviour are *really* just 2-D objects + time.
>
> A button is just a rectangle with a shadow draw round it. When you
> click it it moves down and the shadow changes, a little while later it returns
> to its original position.
>
> I wanted to make a tabbed widget - now you might think that I could
> combine buttons in some kind of hbox - well yes you can but it looks
> terrible. No a tabbed widget viewed as a 2D drawing is "just" a line
> that moves up and down and a few shadows in the appropriate places.
>
> So the way to make a tabbed widget is *not* to compose a hbox of buttons
> but to draw the outline of what you want in 2D and make some regions that
> are sensitive to mouse clicks.
>
> The abstractions you think you need (buttons, sliders) are not the ones that
> are useful from a compositional point of view.
>
> This is actually why I like SVG - there are two abstractions path and group
> - path draws a curve. Group glues objects and has an optional affine
> transformation. All other SVG objects (rectangles, circles, lines,
> ...) can
> be constructed from paths and groups.
>
> Postscript is another *great* and not very well understood language -
> display postscript would be great for GUIs but which is sadly not used.
>
> It's crazy - in the browser it's really easy to mock up an interface
> with SVG or a canvas or by adding things to the DOM - but on the
> desktop it's a pain in the whatnot.
>
> The answer is *not* to bundle the entire browser into a stand alone app
> but to strip out the good parts  and make a minimal system with only
> the good parts (which in my mind is *just* a drawing surface, can a canvas
> or SVG responsive widget) a small scripting language (say Lua or JS) and
> a communication method (say JSON) and transport mechanism (say TCP)
>
> This (of course) is what we do not do :-) - instead everything that has ever
> seen the light of day is bundled into the browser and the parts cannot be
> easily separated.
>
> Cheers
>
> /Joe
>
>
> On Wed, Jul 26, 2017 at 10:20 PM, Albin Stigö <albin.stigo@REDACTED> wrote:
>> 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 <erlang@REDACTED> 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
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions