[erlang-questions] wxErlang

[Richard A. O'Keefe]

> On 6/07/2017, at 7:59 AM, Grzegorz Junka <list1@REDACTED> wrote:
> 
> Furthermore, I would argue that such a representation is better or more natural than representing the UI as independent processes.

Hmm.  One of the web browsers I use is Chrome.  Each Chrome window
is managed by a separate process.  For that matter, I see no great
advantage from having the tabs in a window be in a single address
space.

My department has been doing a fair bit of work with sensor networks.
If I have a window divided into panes showing the reports from say
10 sensors, why do I want that smushed into a single state?

> And that's precisely because it's not enough to know just parts of the global state to update the UI properly, you need to know the whole state.

You have an argument there for the *window manager* needing to know
a lot for rendering onto the screen.  After all, even ex11 routes
all the messages for a display through a single socket.  But that
doesn't mean that the *application* is best structured as a giant
state.

Suppose I have an interface in which pressing a certain button
starts an action that takes a long time, and I decide I want to
stop it.
 - If the UI is completely synchronous, I have to wait until the
   action I want stopped is finished.
 - If the UI is concurrent, the "stop" button should always work.
 - If I'm using Swing, long-running actions are supposed to run
   in a different thread, but that means they can't update the UI.
 - If I'm using other things, I get the joy of using some sort of
   lame simulated concurrency.
(This actually happened to me several times this week, and I had
to resort to "Force Quit" each time.)