[erlang-questions] My quest for a decent way to make a GUI in erlang (Filipe)
Filipe Varjão
varjaofilipe@REDACTED
Thu Jul 27 14:08:02 CEST 2017
I have some experience with Qt Creator, building the GUI first and make the
connection between the buttons and back-end, with separate steps like web
applications.
I strongly recommend.
On Thu, Jul 27, 2017 at 7:00 AM, <erlang-questions-request@REDACTED>
wrote:
> Send erlang-questions mailing list submissions to
> erlang-questions@REDACTED
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://erlang.org/mailman/listinfo/erlang-questions
> or, via email, send a message with subject or body 'help' to
> erlang-questions-request@REDACTED
>
> You can reach the person managing the list at
> erlang-questions-owner@REDACTED
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of erlang-questions digest..."
>
>
> Today's Topics:
>
> 1. Re: My quest for a decent way to make a GUI in erlang
> (Albin Stig?)
> 2. Re: My quest for a decent way to make a GUI in erlang (Unix One)
> 3. Re: My quest for a decent way to make a GUI in erlang
> (Richard A. O'Keefe)
> 4. Re: os:cmd hang on OTP 18 (D?niel Szoboszlay)
> 5. Patch Package OTP 20.0.2 Released (John H?gberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 Jul 2017 02:45:57 +0200
> From: Albin Stig? <albin.stigo@REDACTED>
> To: Joe Armstrong <erlang@REDACTED>
> Cc: Erlang <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] My quest for a decent way to make a
> GUI in erlang
> Message-ID:
> <CAMc++1UG2KNvwpREQtRUhLyq1CHZrWsEmPy
> TbK1hhBSGi61atA@REDACTED>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 Jul 2017 02:03:07 +0000
> From: Unix One <unix1@REDACTED>
> To: Albin Stig? <albin.stigo@REDACTED>, Joe Armstrong
> <erlang@REDACTED>
> Cc: Erlang <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] My quest for a decent way to make a
> GUI in erlang
> Message-ID:
> <BY2PR19MB03755D9CB02781C63B6F64E598BE0@REDACTED
> namprd19.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 Jul 2017 14:53:17 +1200
> From: "Richard A. O'Keefe" <ok@REDACTED>
> To: <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] My quest for a decent way to make a
> GUI in erlang
> Message-ID: <9dbb9326-c196-28f3-3340-fe757ab8d0ef@REDACTED>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
>
>
> 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.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 27 Jul 2017 07:21:20 +0000
> From: D?niel Szoboszlay <dszoboszlay@REDACTED>
> To: Dmytro Lytovchenko <dmytro.lytovchenko@REDACTED>
> Cc: erlang-questions <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] os:cmd hang on OTP 18
> Message-ID:
> <CADcfxonPG7CEX4ieX5YWsYicPC_143bs-78YeiBF0nDoTadi8g@REDACTED
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Dmytro, this really helped a lot!
>
> I think the commit you pointed to is not directly related: it only changes
> Erlang code, and if the behaviour depends on whether you are using a
> release/debug build, the root cause is most probably somewhere in the C
> code of erts.
>
> But the commit message talks about the emulator no longer using vfork, and
> it was a good clue: disabling vfork on 18 prevents the problem. So this one
> will finish:
>
> ERL_NO_VFORK=true erl +A0 +S 1:1 -noinput -noshell -eval 'os:cmd("tar -C
> /tmp/ -xf /tmp/tartest --use-compress-program=lbzip2"), init:stop().'
>
> Thanks again for the clue, I will look into the difference between using
> fork/vfork in OTP 18!
>
> Daniel
>
> On Thu, 27 Jul 2017 at 02:09 Dmytro Lytovchenko <
> dmytro.lytovchenko@REDACTED> wrote:
>
> > I could observe the behaviour only in R18, but not in R19 and not in R20
> > I also could not reproduce it in debug flavour of R18 emulator, but it
> > reproduces reliably in release SMP variant.
> >
> > The changes to os.erl between 18.3.4.5 and 19.0 include removal of os:cmd
> > server which might somehow be related (commit
> > *200247f972b012ced0c4b2c6611f091af66ebedd*). This commit *possibly*
> fixes
> > the behavior ? in R19 (build 19.0 by Kerl) the behaviour does not happen.
> >
> > 2017-07-26 21:47 GMT+02:00 D?niel Szoboszlay <dszoboszlay@REDACTED>:
> >
> >> Honestly, I didn't try with other command variations. There are many
> >> commands that do not hang when run from os:cmd, regardless of the OTP
> >> version. But this particular command does hang with one OTP version, and
> >> not with the other OTP version. So the difference is in OTP, and I want
> to
> >> find out what has changed.
> >>
> >> Daniel
> >>
> >> On Wed, 26 Jul 2017 at 21:34 Dmytro Lytovchenko <
> >> dmytro.lytovchenko@REDACTED> wrote:
> >>
> >>> Is it something lbzip2 related?
> >>> Did you try normal single-thread bzip2? (-j flag or --bzip2)
> >>> What is you use gzip? (-z or --gzip)
> >>>
> >>> 2017-07-26 21:27 GMT+02:00 D?niel Szoboszlay <dszoboszlay@REDACTED>:
> >>>
> >>>> Hi,
> >>>>
> >>>> I've encountered a strange problem with os:cmd when running tar and
> >>>> lbzip2. Steps to reproduce:
> >>>>
> >>>> # create some lbzip2 compressed data
> >>>>
> >>>> dd if=/dev/urandom of=/tmp/testfile count=10
> >>>> tar -cf - -C /tmp testfile | lbzip2 -6 -n 4 | dd of=/tmp/tartest
> status=none
> >>>>
> >>>>
> >>>> # try to extract the archive from Erlang with os:cmd
> >>>>
> >>>> erl -noinput -eval 'os:cmd("tar -C /tmp/ -xf /tmp/tartest
> --use-compress-program=lbzip2"), init:stop().'
> >>>>
> >>>>
> >>>> This worked fine with OTP 17.5.6.7, but with OTP 18.3.4.5 the command
> >>>> hangs: lbzip2 just sits in a rt_sigsuspend syscall waiting for a
> USR2, PIPE
> >>>> or XFSZ signal. And its parent, the tar process waits in a wait4
> syscall
> >>>> for lbzip2 to terminate.
> >>>>
> >>>> I don't have at the moment any newer OTP version installed, I'm not
> >>>> sure how OTP 19 or 20 would behave.
> >>>>
> >>>> I tried to strace the processes, but there's too much noise, I
> couldn't
> >>>> yet figure out anything interesting there.
> >>>>
> >>>> I also tried to diff OTP 17 & 18, but os:cmd/1 and friends didn't
> >>>> change. I'm not sure about the port code, but at least the release
> notes
> >>>> didn't mention anything major. Or did I miss something? Does anyone
> have an
> >>>> idea what may have changed between these OTP versions?
> >>>>
> >>>> Thanks,
> >>>> Daniel
> >>>>
> >>>> _______________________________________________
> >>>> 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/
> 20170727/2c790fa8/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 27 Jul 2017 07:30:05 +0000
> From: John H?gberg <john.hogberg@REDACTED>
> To: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> Subject: [erlang-questions] Patch Package OTP 20.0.2 Released
> Message-ID:
> <AM4PR07MB149062967A47EAB472EADEBEF6BE0@REDACTED
> eurprd07.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Patch Package: OTP 20.0.2
> Git Tag: OTP-20.0.2
> Date: 2017-07-27
> Trouble Report Id: OTP-14494, OTP-14498, OTP-14509, OTP-14514,
> OTP-14519
> Seq num: ERIERL-49
> System: OTP
> Release: 20
> Application: asn1-5.0.1, erts-9.0.2, kernel-5.3.1
> Predecessor: OTP 20.0.1
>
> Check out the git tag OTP-20.0.2, and build a full OTP system
> including documentation. Apply one or more applications from this
> build as patches to your installation using the 'otp_patch_apply'
> tool. For information on install requirements, see descriptions for
> each application version below.
>
> ---------------------------------------------------------------------
> --- asn1-5.0.1 ------------------------------------------------------
> ---------------------------------------------------------------------
>
> The asn1-5.0.1 application can be applied independently of other
> applications on a full OTP 20 installation.
>
> --- Fixed Bugs and Malfunctions ---
>
> OTP-14519 Application(s): asn1
> Related Id(s): ERIERL-49
>
> Fixed compilation error of generated code caused by a
> missing quotation of function names as part of an
> external call for encoding.
>
>
> Full runtime dependencies of asn1-5.0.1: erts-7.0, kernel-3.0,
> stdlib-2.0
>
>
> ---------------------------------------------------------------------
> --- erts-9.0.2 ------------------------------------------------------
> ---------------------------------------------------------------------
>
> The erts-9.0.2 application can be applied independently of other
> applications on a full OTP 20 installation.
>
> --- Fixed Bugs and Malfunctions ---
>
> OTP-14494 Application(s): erts
>
> Added missing release notes for OTP-14491 ("performance
> bug in pre-allocators") which was included in
> erts-9.0.1 (OTP-20.0.1).
>
>
> OTP-14509 Application(s): erts
>
> Fixed a bug that prevented TCP sockets from being
> closed properly on send timeouts.
>
>
> OTP-14514 Application(s): erts
>
> Fixed bug in operator bxor causing erroneuos result
> when one operand is a big *negative* integer with the
> lowest N*W bits as zero and the other operand not
> larger than N*W bits. N is an integer of 1 or larger
> and W is 32 or 64 depending on word size.
>
>
> Full runtime dependencies of erts-9.0.2: kernel-5.0, sasl-3.0.1,
> stdlib-3.0
>
>
> ---------------------------------------------------------------------
> --- kernel-5.3.1 ----------------------------------------------------
> ---------------------------------------------------------------------
>
> The kernel-5.3.1 application can be applied independently of other
> applications on a full OTP 20 installation.
>
> --- Fixed Bugs and Malfunctions ---
>
> OTP-14498 Application(s): kernel
>
> The documentation for the 'quiet' option in
> disk_log:open/1 had an incorrect default value.
>
>
> Full runtime dependencies of kernel-5.3.1: erts-9.0, sasl-3.0,
> stdlib-3.0
>
>
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
>
>
> ------------------------------
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> End of erlang-questions Digest, Vol 332, Issue 5
> ************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170727/8046a506/attachment.htm>
More information about the erlang-questions
mailing list