My quest for a decent way to make a GUI in erlang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

My quest for a decent way to make a GUI in erlang

Joe Armstrong-2
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Lloyd R. Prentice-2

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" <[hidden email]>
Sent: Wednesday, July 26, 2017 1:45pm
To: "Erlang" <[hidden email]>
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Albin Stigö-2
In reply to this post by Joe Armstrong-2
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 <[hidden email]> 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Joe Armstrong-2
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ö <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Albin Stigö-2
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 <[hidden email]> 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ö <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Unix One
In reply to this post by Albin Stigö-2
On 07/26/2017 01:20 PM, Albin Stigö wrote:

> QT has signals and slots.
>

I haven't done big projects in Qt, but little fiddling I did with a
small GUI app, I found Qt+QML a pleasure to work with.

Searching for Erlang-related examples, it just took about 30 secs to try
this on my laptop:

https://github.com/krant/eqml

It's showing passing Erlang messages as signals to Qt slots and vice
versa. If I were doing GUIs with Erlang, this would be one place I'd
look closer.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in erlang

Richard A. O'Keefe-2
In reply to this post by Albin Stigö-2


On 27/07/17 12:45 PM, Albin Stigö wrote:
> 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?

Before Display Postscript (developed for Apple)
there was NeWS.  See the NeWS book at
http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Book_1989.pdf

Programming in a concurrent OO extension of Postscript never really
appealed to me, and the performance issues of thread decades ago
probably look quite different today with GPUs.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: My quest for a decent way to make a GUI in Erlang

Onorio Catenacci
In reply to this post by Joe Armstrong-2
First of all, thanks Joe for feeding my magpie developer syndrome with more cool new stuff to look at! 

Secondly, I'm glad to see that I'm not the only one who remembers the idea of building a GUI for a desktop app.  The default answer for most all developers seems to be slap together a webapp--which is fine for a lot of situations but there are definite advantages to a genuine GUI on a desktop app. 

Sadly it seems to be the case that a lot of developers are opting to learn JavaScript and all the hacks needed to make that a viable platform than learning better ways of doing things.  That seems to follow from the "everything must be a webapp" school of thinking. 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions