[erlang-questions] wxErlang

[Grzegorz Junka]

On 06/07/2017 02:08, Richard A. O'Keefe wrote:
>> 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?

You are adding an additional level of abstraction. Each tab is a 
separate UI and then the arrangement of all tabs/browsers on the screen 
is yet another UI. Surely, each UI requires a separate process because 
there is no shared state between them. But then again, there is no 
reason for the main UI (showing all the tabs) to be split into separate 
processes/states. You can of course optimize the rendering by extracting 
some calculations into separate threads so that the main rendering 
thread isn't being blocked by them. But it's an optimization not 
changing the fact that each UI is ultimately based on one 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.

We are talking about the UI here, which is not the same as application. 
UI is the view of the application and the state of the UI is something 
separate to the state of the application.

> 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.)
>

You are mixing the UI with the application. The fact that UI is 
synchronous doesn't mean that the whole application needs to be 
synchronous. I am arguing that UI should be represented as a single 
process dependent on a single state, but that process shouldn't be the 
same as the main process of the application. The application runs as 
many independent processes (IO, data model, processing, etc). That's 
independent of the UI. When any data that needs to be displayed changes 
the application process communicates the change to the UI process which 
takes care of displaying that change correctly considering all other UI 
elements on the page that it knows about from the single UI state.

Grzegorz