wxErlang - some answers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

wxErlang - some answers

Joe Armstrong-2
I'm trying to get to grips with wxErlang so I toddled over to Ericsson
and sat down for a few hours with Dan Gudmundsson and asked him a boat
load of stupid questions.

I'll be writing a lot more about this and setting up a github project
to document how to get tame wxErlang ...

Here's a first attempt at figuring out how things work.

My usual approach to understanding things is always the same.

"Take a program that works. Then remove non-essential bits until
all that is left is so simple that you can understand it."

How about making some buttons - this should be easy

I started with demo.erl in ${ERL_TOP}/lib/wx/examples/demo/demo.erl

This has some code for making buttons - but it also does *a lot more*
and *it is highly redundant* -- from the point of view of learning the
code volume does not assist comprehension, nor does using a generic behavior.

What do I mean by this?

   - ex_button.erl is written using wx_object.erl
     so to understand ex_button.erl I have to also understand wx_object.erl
   - ex_button.erl has repeated code. For example
     several buttons have tooltips, but I only need to be shown how to do this
     *once* not several times
   - ex_button.erl introduces several new concepts - in particular spacers
     and sizers - and I haven't a clue what they do.

Now I'm going to refactor ex_button.erl so take a deep breath ...

First refactoring: remove the dependency on wx_object

I'd already figured out that a *minimal* wx windows program is:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        wxFrame:show(Frame).

To make the window do something I'd want to write:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        setup_window(Frame),
        wxFrame:show(Frame),
        loop().

    loop() ->
        receive
            Any ->
                io:format("Any=~p~n",[Any])
        end,
        loop().

Given this structure I refactored ex_button.erl into buttons_demo.erl
which removes all the wx_object code. So now I can stare are the code
in buttons_demo.erl and see if I can understand it, for my point of
view it's far easier to understand than ex_buttons.erl since there is
no dependency on wx_object.erl

Second refactoring: Simplify buttons_demo.erl

The original program has four rows of buttons - but one will
be sufficient for me.

I now removed many lines of code, until only one line of buttons
remained.

The resulting code buttons_demo1.erl now only creates one line of buttons
and has a couple of sizers.

Dan told me that the line of code:

   wxStaticBoxSizer:new(?wxHORIZONTAL, Panel,[{label, "wxButton"}]),

Is wxWidgets way of making an hbox - Goodness wxWidgets can be build
using Knuthian hboxes and vboxes (horray).

I'm still not happy with buttons_demo1.erl since it mixes two ideas:

   - making buttons
   - putting buttons in a container and laying out the containers

This needs to be refactored into:

   - a pure button examples
   - a pure layout example

My intention is to try and decompose wxErlang into a large number of
small examples, where each example illustrates one feature of the
system. Also so show how to build complex examples from the small
parts.

I'll make all the code available on github so you can join in the fun
(is this fun?).

Notes:

[1] Feel free to send me examples of wxErlang code - preferably
one example per module that illustrates one feature.

[2] Anybody want to do this for elixir?

[3] The WxWidgets documentation is a terminological mess - they call
*everything* (including a button) a window.

[4] The WxWidget examples (in C++) require subclassing several objects
resulting in multiple files per example - the Erlang equivalent is
nicely contained within a single module (which is far nicer)

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

ex_button.erl (9K) Download Attachment
buttons_demo.erl (7K) Download Attachment
buttons_demo1.erl (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang - some answers

Frank Muller
Joe,

What about the idea behind "GTK server":

Best
/Frank

Le mar. 4 juil. 2017 à 18:18, Joe Armstrong <[hidden email]> a écrit :
I'm trying to get to grips with wxErlang so I toddled over to Ericsson
and sat down for a few hours with Dan Gudmundsson and asked him a boat
load of stupid questions.

I'll be writing a lot more about this and setting up a github project
to document how to get tame wxErlang ...

Here's a first attempt at figuring out how things work.

My usual approach to understanding things is always the same.

"Take a program that works. Then remove non-essential bits until
all that is left is so simple that you can understand it."

How about making some buttons - this should be easy

I started with demo.erl in ${ERL_TOP}/lib/wx/examples/demo/demo.erl

This has some code for making buttons - but it also does *a lot more*
and *it is highly redundant* -- from the point of view of learning the
code volume does not assist comprehension, nor does using a generic behavior.

What do I mean by this?

   - ex_button.erl is written using wx_object.erl
     so to understand ex_button.erl I have to also understand wx_object.erl
   - ex_button.erl has repeated code. For example
     several buttons have tooltips, but I only need to be shown how to do this
     *once* not several times
   - ex_button.erl introduces several new concepts - in particular spacers
     and sizers - and I haven't a clue what they do.

Now I'm going to refactor ex_button.erl so take a deep breath ...

First refactoring: remove the dependency on wx_object

I'd already figured out that a *minimal* wx windows program is:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        wxFrame:show(Frame).

To make the window do something I'd want to write:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        setup_window(Frame),
        wxFrame:show(Frame),
        loop().

    loop() ->
        receive
            Any ->
                io:format("Any=~p~n",[Any])
        end,
        loop().

Given this structure I refactored ex_button.erl into buttons_demo.erl
which removes all the wx_object code. So now I can stare are the code
in buttons_demo.erl and see if I can understand it, for my point of
view it's far easier to understand than ex_buttons.erl since there is
no dependency on wx_object.erl

Second refactoring: Simplify buttons_demo.erl

The original program has four rows of buttons - but one will
be sufficient for me.

I now removed many lines of code, until only one line of buttons
remained.

The resulting code buttons_demo1.erl now only creates one line of buttons
and has a couple of sizers.

Dan told me that the line of code:

   wxStaticBoxSizer:new(?wxHORIZONTAL, Panel,[{label, "wxButton"}]),

Is wxWidgets way of making an hbox - Goodness wxWidgets can be build
using Knuthian hboxes and vboxes (horray).

I'm still not happy with buttons_demo1.erl since it mixes two ideas:

   - making buttons
   - putting buttons in a container and laying out the containers

This needs to be refactored into:

   - a pure button examples
   - a pure layout example

My intention is to try and decompose wxErlang into a large number of
small examples, where each example illustrates one feature of the
system. Also so show how to build complex examples from the small
parts.

I'll make all the code available on github so you can join in the fun
(is this fun?).

Notes:

[1] Feel free to send me examples of wxErlang code - preferably
one example per module that illustrates one feature.

[2] Anybody want to do this for elixir?

[3] The WxWidgets documentation is a terminological mess - they call
*everything* (including a button) a window.

[4] The WxWidget examples (in C++) require subclassing several objects
resulting in multiple files per example - the Erlang equivalent is
nicely contained within a single module (which is far nicer)
_______________________________________________
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
|  
Report Content as Inappropriate

diameter server - overload protection

Aleksander Nycz-2

Hello,


We try to implement overload protection into diameter server that uses erlang diameter-2.0 application.

Our overload policy use queuing time and queue lenght to determine if server is overloaded or not.


Currently it is quite hard to check when diameter packet was received by diameter stack,

so I would like to add to diameter_packet record (defined in diameter.hrl) receive_time field like this:

-record(diameter_packet,
        {header,     %% #diameter_header{}
         avps,       %% deep list() of #diameter_avp{}
         msg,        %% fully decoded message
         bin,        %% binary received/sent over the wire
         errors = [],%% list() of Result-Code | {Result-Code, #diameter_avp{}}
         transport_data,
         receive_time = erlang:monotonic_time() %% integer()
         }).

What do you think about it?

It will be possible to merge this into diameter app release with OTP 20.1?


Best Regards

Aleksander Nycz


-- 
Aleksander Nycz
Chief Designer
Telco_021 BSS R&D
Comarch SA
Phone:  +48 17 785 5909
Mobile: +48 691 464 275
website: www.comarch.pl

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diameter server - overload protection

Anders G S Svensson
Hi Aleksander.

Changing diameter_packet will create a fair deal of upgrade woe, but
you can use a message_cb option to diameter_{tcp,sctp} to set the time
in diameter_packet.transport_data.

(None of which is documented yet, but probably in 20.1.)

Anders



[hidden email] writes:

> Message: 10
> Date: Thu, 6 Jul 2017 11:41:34 +0200
> From: Aleksander Nycz <[hidden email]>
> To: [hidden email]
> Subject: [erlang-questions]  diameter server - overload protection
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hello,
>
>
> We try to implement overload protection into diameter server that uses
> erlang diameter-2.0 application.
>
> Our overload policy use queuing time and queue lenght to determine if
> server is overloaded or not.
>
>
> Currently it is quite hard to check when diameter packet was received by
> diameter stack,
>
> so I would like to add to diameter_packet record (defined in
> diameter.hrl) receive_time field like this:
>
> -record(diameter_packet,
>          {header,%% #diameter_header{} avps,%% deep list() of #diameter_avp{} msg,%% fully decoded message bin,%% binary received/sent over the wire errors = [],%% list() of Result-Code | {Result-Code, #diameter_avp{}} transport_data,
>           *receive_time = erlang:monotonic_time() **%% integer()* }).
>
>
> What do you think about it?
>
> It will be possible to merge this into diameter app release with OTP 20.1?
>
>
> Best Regards
>
> Aleksander Nycz
>
>
> --
> Aleksander Nycz
> Chief Designer
> Telco_021 BSS R&D
> Comarch SA
> Phone:  +48 17 785 5909
> Mobile: +48 691 464 275
> website: www.comarch.pl
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang - some answers

Joe Armstrong-2
In reply to this post by Frank Muller
I'd forgotten about the GTK server - I played with it years ago - has
anybody any experience with building this on various platforms?

/Joe

On Thu, Jul 6, 2017 at 9:56 AM, Frank Muller <[hidden email]> wrote:

> Joe,
>
> What about the idea behind "GTK server":
> http://www.gtk-server.org/
>
> Best
> /Frank
>
> Le mar. 4 juil. 2017 à 18:18, Joe Armstrong <[hidden email]> a écrit :
>>
>> I'm trying to get to grips with wxErlang so I toddled over to Ericsson
>> and sat down for a few hours with Dan Gudmundsson and asked him a boat
>> load of stupid questions.
>>
>> I'll be writing a lot more about this and setting up a github project
>> to document how to get tame wxErlang ...
>>
>> Here's a first attempt at figuring out how things work.
>>
>> My usual approach to understanding things is always the same.
>>
>> "Take a program that works. Then remove non-essential bits until
>> all that is left is so simple that you can understand it."
>>
>> How about making some buttons - this should be easy
>>
>> I started with demo.erl in ${ERL_TOP}/lib/wx/examples/demo/demo.erl
>>
>> This has some code for making buttons - but it also does *a lot more*
>> and *it is highly redundant* -- from the point of view of learning the
>> code volume does not assist comprehension, nor does using a generic
>> behavior.
>>
>> What do I mean by this?
>>
>>    - ex_button.erl is written using wx_object.erl
>>      so to understand ex_button.erl I have to also understand
>> wx_object.erl
>>    - ex_button.erl has repeated code. For example
>>      several buttons have tooltips, but I only need to be shown how to do
>> this
>>      *once* not several times
>>    - ex_button.erl introduces several new concepts - in particular spacers
>>      and sizers - and I haven't a clue what they do.
>>
>> Now I'm going to refactor ex_button.erl so take a deep breath ...
>>
>> First refactoring: remove the dependency on wx_object
>>
>> I'd already figured out that a *minimal* wx windows program is:
>>
>>     start() ->
>>         Wx = wx_win:new(),
>>         Frame = wxFrame:new(Wx, -1, "Window Title"),
>>         wxFrame:show(Frame).
>>
>> To make the window do something I'd want to write:
>>
>>     start() ->
>>         Wx = wx_win:new(),
>>         Frame = wxFrame:new(Wx, -1, "Window Title"),
>>         setup_window(Frame),
>>         wxFrame:show(Frame),
>>         loop().
>>
>>     loop() ->
>>         receive
>>             Any ->
>>                 io:format("Any=~p~n",[Any])
>>         end,
>>         loop().
>>
>> Given this structure I refactored ex_button.erl into buttons_demo.erl
>> which removes all the wx_object code. So now I can stare are the code
>> in buttons_demo.erl and see if I can understand it, for my point of
>> view it's far easier to understand than ex_buttons.erl since there is
>> no dependency on wx_object.erl
>>
>> Second refactoring: Simplify buttons_demo.erl
>>
>> The original program has four rows of buttons - but one will
>> be sufficient for me.
>>
>> I now removed many lines of code, until only one line of buttons
>> remained.
>>
>> The resulting code buttons_demo1.erl now only creates one line of buttons
>> and has a couple of sizers.
>>
>> Dan told me that the line of code:
>>
>>    wxStaticBoxSizer:new(?wxHORIZONTAL, Panel,[{label, "wxButton"}]),
>>
>> Is wxWidgets way of making an hbox - Goodness wxWidgets can be build
>> using Knuthian hboxes and vboxes (horray).
>>
>> I'm still not happy with buttons_demo1.erl since it mixes two ideas:
>>
>>    - making buttons
>>    - putting buttons in a container and laying out the containers
>>
>> This needs to be refactored into:
>>
>>    - a pure button examples
>>    - a pure layout example
>>
>> My intention is to try and decompose wxErlang into a large number of
>> small examples, where each example illustrates one feature of the
>> system. Also so show how to build complex examples from the small
>> parts.
>>
>> I'll make all the code available on github so you can join in the fun
>> (is this fun?).
>>
>> Notes:
>>
>> [1] Feel free to send me examples of wxErlang code - preferably
>> one example per module that illustrates one feature.
>>
>> [2] Anybody want to do this for elixir?
>>
>> [3] The WxWidgets documentation is a terminological mess - they call
>> *everything* (including a button) a window.
>>
>> [4] The WxWidget examples (in C++) require subclassing several objects
>> resulting in multiple files per example - the Erlang equivalent is
>> nicely contained within a single module (which is far nicer)
>> _______________________________________________
>> 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
|  
Report Content as Inappropriate

Re: wxErlang - some answers

Alex S.
In reply to this post by Frank Muller
The prog21.dadgum.com guy, James Hague, puts forth that he writes a GUI controller in another language and uses that as a port to communicate with. May that be a fruitful approach?

6 июля 2017 г. 10:56 AM пользователь "Frank Muller" <[hidden email]> написал:
Joe,

What about the idea behind "GTK server":

Best
/Frank

Le mar. 4 juil. 2017 à 18:18, Joe Armstrong <[hidden email]> a écrit :
I'm trying to get to grips with wxErlang so I toddled over to Ericsson
and sat down for a few hours with Dan Gudmundsson and asked him a boat
load of stupid questions.

I'll be writing a lot more about this and setting up a github project
to document how to get tame wxErlang ...

Here's a first attempt at figuring out how things work.

My usual approach to understanding things is always the same.

"Take a program that works. Then remove non-essential bits until
all that is left is so simple that you can understand it."

How about making some buttons - this should be easy

I started with demo.erl in ${ERL_TOP}/lib/wx/examples/demo/demo.erl

This has some code for making buttons - but it also does *a lot more*
and *it is highly redundant* -- from the point of view of learning the
code volume does not assist comprehension, nor does using a generic behavior.

What do I mean by this?

   - ex_button.erl is written using wx_object.erl
     so to understand ex_button.erl I have to also understand wx_object.erl
   - ex_button.erl has repeated code. For example
     several buttons have tooltips, but I only need to be shown how to do this
     *once* not several times
   - ex_button.erl introduces several new concepts - in particular spacers
     and sizers - and I haven't a clue what they do.

Now I'm going to refactor ex_button.erl so take a deep breath ...

First refactoring: remove the dependency on wx_object

I'd already figured out that a *minimal* wx windows program is:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        wxFrame:show(Frame).

To make the window do something I'd want to write:

    start() ->
        Wx = wx_win:new(),
        Frame = wxFrame:new(Wx, -1, "Window Title"),
        setup_window(Frame),
        wxFrame:show(Frame),
        loop().

    loop() ->
        receive
            Any ->
                io:format("Any=~p~n",[Any])
        end,
        loop().

Given this structure I refactored ex_button.erl into buttons_demo.erl
which removes all the wx_object code. So now I can stare are the code
in buttons_demo.erl and see if I can understand it, for my point of
view it's far easier to understand than ex_buttons.erl since there is
no dependency on wx_object.erl

Second refactoring: Simplify buttons_demo.erl

The original program has four rows of buttons - but one will
be sufficient for me.

I now removed many lines of code, until only one line of buttons
remained.

The resulting code buttons_demo1.erl now only creates one line of buttons
and has a couple of sizers.

Dan told me that the line of code:

   wxStaticBoxSizer:new(?wxHORIZONTAL, Panel,[{label, "wxButton"}]),

Is wxWidgets way of making an hbox - Goodness wxWidgets can be build
using Knuthian hboxes and vboxes (horray).

I'm still not happy with buttons_demo1.erl since it mixes two ideas:

   - making buttons
   - putting buttons in a container and laying out the containers

This needs to be refactored into:

   - a pure button examples
   - a pure layout example

My intention is to try and decompose wxErlang into a large number of
small examples, where each example illustrates one feature of the
system. Also so show how to build complex examples from the small
parts.

I'll make all the code available on github so you can join in the fun
(is this fun?).

Notes:

[1] Feel free to send me examples of wxErlang code - preferably
one example per module that illustrates one feature.

[2] Anybody want to do this for elixir?

[3] The WxWidgets documentation is a terminological mess - they call
*everything* (including a button) a window.

[4] The WxWidget examples (in C++) require subclassing several objects
resulting in multiple files per example - the Erlang equivalent is
nicely contained within a single module (which is far nicer)
_______________________________________________
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


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

Re: wxErlang - some answers

PAILLEAU Eric
In reply to this post by Joe Armstrong-2
Hello Joe,

I'm particularly interested in XRC [1] standard.

I think your effort, and efforts of people helping, may be a step to
create XSLT templates to write wx abstract code to help people create
easily wx UI without the huge effort to understand basics of wx.
wx documentation is intimidating (well like was Erlang documentation
first time I looked at it many years ago :) ...) but much harder than it
  to be able to write code quickly.

Those templates could be a plugin in usual build tools to handle .xrc
files, like asn1 file are handled to create code.

If I can help, I will !

>
> My intention is to try and decompose wxErlang into a large number of
> small examples, where each example illustrates one feature of the
> system. Also so show how to build complex examples from the small
> parts.
>
> I'll make all the code available on github so you can join in the fun
> (is this fun?).

[1] http://docs.wxwidgets.org/trunk/overview_xrc.html

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

Re: wxErlang - some answers

Vlad Dumitrescu-2
Hi Joe, 

I wonder -- from this point of view of the APIs, what do you think of the now defunct `gs` application?

People have given good feedback, but I will add my 2c too. There are several issues to solve. 

One issue is "how do I put the GUI together?", which IMHO is best done declaratively. With an adequate language, even dynamic UIs can be described. This is relatively easy.

The second issue is handling the state: bot the application state (what the real app needs to know from the inputs) and the GUI state (for example, a checkbox controlling the enabled state of the rest of the controls on the page; or an input validator for the whole UI). The latter is the tricky one, in my experience, as some entity needs to have the whole state available. Updates to this states need to be observed, which is not easy to do correctly (see even below).

Then there is the issue of performance, again two-sided: 
- we'd like to be able to use native controls/widgets, but allow custom ones too. Here we also stumble upon supporting all OSs and graphics frameworks.
- updating the UI needs to be done at the appropriate moments, i.e. if needed and not more often than the display can update itself.

There is one technology that is available everywhere, has optimized rendering and is reasonably easy to adapt and adapt to: HTML. With frameworks like Electron (https://electron.atom.io/), it is available on the desktop and with the full power of JavaScript. Web components are on the rise and there are libraries (vue.js, https://vuejs.org/, for example) that make them easy to build and reason about. The remaining issue however is an interesting hurdle: how to interface JS with Erlang? There have been interesting projects for that (like beam.js and erlv8), but I can't find any active one - it would be interesting to know what what the reason was for not continuing the work.

best regards,
Vlad


On Sat, Jul 8, 2017 at 11:28 AM, PAILLEAU Eric <[hidden email]> wrote:
Hello Joe,

I'm particularly interested in XRC [1] standard.

I think your effort, and efforts of people helping, may be a step to create XSLT templates to write wx abstract code to help people create easily wx UI without the huge effort to understand basics of wx.
wx documentation is intimidating (well like was Erlang documentation first time I looked at it many years ago :) ...) but much harder than it  to be able to write code quickly.

Those templates could be a plugin in usual build tools to handle .xrc files, like asn1 file are handled to create code.

If I can help, I will !


My intention is to try and decompose wxErlang into a large number of
small examples, where each example illustrates one feature of the
system. Also so show how to build complex examples from the small
parts.

I'll make all the code available on github so you can join in the fun
(is this fun?).

[1] http://docs.wxwidgets.org/trunk/overview_xrc.html


_______________________________________________
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
|  
Report Content as Inappropriate

Re: wxErlang - some answers

Joe Armstrong-2
On Sat, Jul 8, 2017 at 9:10 PM, Vlad Dumitrescu <[hidden email]> wrote:
> Hi Joe,
>
> I wonder -- from this point of view of the APIs, what do you think of the
> now defunct `gs` application?

Hello Vlad,

I'd always liked gs - the trouble seems to be (I might be wrong here)
that TCL/Tk
is no longer popular and untrendy. Also my impression was that the
GUI's you could make
deviated from the current look-and-feel that people expect.

>
> People have given good feedback, but I will add my 2c too. There are several
> issues to solve.
>
> One issue is "how do I put the GUI together?", which IMHO is best done
> declaratively. With an adequate language, even dynamic UIs can be described.
> This is relatively easy.

I agree - actually wxWidgets has hboxes and vboxes so this should be
"relatively" easy.
Relatively being a relative term here :-)


> The second issue is handling the state: bot the application state (what the
> real app needs to know from the inputs) and the GUI state (for example, a
> checkbox controlling the enabled state of the rest of the controls on the
> page; or an input validator for the whole UI). The latter is the tricky one,
> in my experience, as some entity needs to have the whole state available.
> Updates to this states need to be observed, which is not easy to do
> correctly (see even below).

Yes - I see this as a concurrency problem. If all the controls on the
GUI either send or
respond to messages is the control program one or several processes?

>
> Then there is the issue of performance, again two-sided:
> - we'd like to be able to use native controls/widgets, but allow custom ones
> too. Here we also stumble upon supporting all OSs and graphics frameworks.
> - updating the UI needs to be done at the appropriate moments, i.e. if
> needed and not more often than the display can update itself.

Tricky

>
> There is one technology that is available everywhere, has optimized
> rendering and is reasonably easy to adapt and adapt to: HTML. With
> frameworks like Electron (https://electron.atom.io/), it is available on the
> desktop and with the full power of JavaScript. Web components are on the
> rise and there are libraries (vue.js, https://vuejs.org/, for example) that
> make them easy to build and reason about. The remaining issue however is an
> interesting hurdle: how to interface JS with Erlang? There have been
> interesting projects for that (like beam.js and erlv8), but I can't find any
> active one - it would be interesting to know what what the reason was for
> not continuing the work.

Ummm - the problem with web technologies is the gigantic size and complexity of
everything - webkit + JS is great - but huge.

The problem is what I want is (say) a graphics widget that responds to
messages containing SVG - and NOTHING ELSE. This is *easy* to do in the
browser BUT I get a lot of other stuff that I don't want.

I think I once found a project that bundled a web browser canvas + JS
into a single program
with nothing else - this would be great if it exists.

The thing I'd like would have (say) the web browser canvas object, JS
and a socket support.

When looking for wxWidgets examples I stumbled over wxLua - which
looks like a good
source of inspiration (has anybody reading this used wXLua???)

Cheers

/Joe




>
> best regards,
> Vlad
>
>
> On Sat, Jul 8, 2017 at 11:28 AM, PAILLEAU Eric <[hidden email]>
> wrote:
>>
>> Hello Joe,
>>
>> I'm particularly interested in XRC [1] standard.
>>
>> I think your effort, and efforts of people helping, may be a step to
>> create XSLT templates to write wx abstract code to help people create easily
>> wx UI without the huge effort to understand basics of wx.
>> wx documentation is intimidating (well like was Erlang documentation first
>> time I looked at it many years ago :) ...) but much harder than it  to be
>> able to write code quickly.
>>
>> Those templates could be a plugin in usual build tools to handle .xrc
>> files, like asn1 file are handled to create code.
>>
>> If I can help, I will !
>>
>>>
>>> My intention is to try and decompose wxErlang into a large number of
>>> small examples, where each example illustrates one feature of the
>>> system. Also so show how to build complex examples from the small
>>> parts.
>>>
>>> I'll make all the code available on github so you can join in the fun
>>> (is this fun?).
>>
>>
>> [1] http://docs.wxwidgets.org/trunk/overview_xrc.html
>>
>>
>> _______________________________________________
>> 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
Loading...