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

Wed Jul 26 20:52:35 CEST 2017

Hi Joe,

Outstanding research!

I've been flailing around a similar problem with dim lights of success here and there.

We all know that there are issues with your long-in-the-tooth erlguten library.

I've pulled out the font management and copy-fitting routines, made slight modifications, and have been building up a page-layout program. At the moment I'm focusing on PDF, but many underlying concepts apply to HTML and desktop GUIs as well.

So first thing I'd note, is that you may be dealing with an even more general problem than you think-- e.g. how to display content in a 2D space for most effective communication of intent between content creator and consumer. In the case of GUIs, the roles of content creator and consumer shift back and forth like a ping pong game.

Print graphic designers have long experience and established techniques for approaching the problem.

They first divide the 2D space into a page grid--- essentially a composition of boxes. You'll find many approaches and theories of how best to design page grids on the web.

Turns our that boxes can be comprehensively represented as maps in Erlang. Taken a step further, no reason why a box can't be moved, re dimensioned, scaled, etc., in an Erlang process.

Box parameters include xy position of upper-left corner in the 2D space, width, height, and various other application-specific parameters--- borders, background color/image, content, etc.

With this thought in mind, I've been working on a box language to efficiently define a page grid in Erlang. What I have works, but no doubt can be improved and optimized.

Next thought is what goes into each box in the page grid--- text, images, graphics, Erlang functions... Hey, "widgets" if you will.

Most all of this can be abstractly defined without regard to media--- print or video.

Box mind-set can be focused down on widgets.

A widget is a composition of visual elements in a contained space. Visual elements include text, icons, boxes, etc. Text and icons can be abstractly represented as boxes. Boxes all the way down.

So, my fantasy---

1. Perfect the box language--- may be two versions: a) text description; b) point, click, and drag
2. Perfect an abstract language to define content elements
3. Define the base visual/functional elements of the content language
4. Develop libraries of base elements for both print and video display

If we're smart and shrewd, we end up with an efficient way to generate both print and video display pages in a common language that effectively communicates intent.

I know that this is all warmed-over-soup. Just watch a handful of TV commercials to see how effectively graphic designers convey intent in 2D spaces or consider the communication issues in 3D CAD programs and how they've been resolved.

But I want to do it in Erlang and am currently working in my clumsy way to do so.

All the best,

Lloyd

-----Original Message-----
From: "Joe Armstrong" <erlang@REDACTED>
Sent: Wednesday, July 26, 2017 1:45pm
To: "Erlang" <erlang-questions@REDACTED>
Subject: [erlang-questions] My quest for a decent way to make a GUI in erlang

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170726/1b9a3b2e/attachment.htm>