Thu Jul 6 10:53:30 CEST 2017
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
> 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
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.
More information about the erlang-questions