Re: Ada-Oriented GUI

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 21/03/2018 15:30, Dan'l Miller wrote:

> Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.

Scheduling implies that order of events is not preserved, right? How 
consistency is achieved?

>> or inversion when a button emits events, but
>> it is the handler that must process them, so the case-statement or
>> dispatching choice constrained by button interface must be in the
>> handler code, not in the button or its descendant.
> 
> In Rx, a different locality-of-reference is the guiding software-architectural principle:  the app-domain source code that instantiated a collection of GUI element(s) (e.g., button and its containing window/view) then almost immediately ‘declares’ (unfortunately via imperative function invocations in today's era of languages) who is to handle those events & on which threads those events are to be scheduled.

That looks like inversion, exactly, when a method is bound to the 
instance of a source GUI element and not the instance of the target. 
(e.g. to the button rather than the container box holding the button).

> “I want this river of events and that river of events and yet another river of events and still another river of events handled sanely even if interleaved arbitrarily without any of the events interrupting or conflicting with the processing of any of the other events.”

That sounds like an excellent source of deadlocks and live-locks.

But the main question is lack of structure. The hierarchy of events is 
of interest, flows do not matter.

Any GUI has 3 dimensions:

1. Events (click)
2. Containment (parent-child)
3. Functional hierarchy (button-toggle button)

Only one of them can be mapped onto a hierarchy of types. Most GUI 
choose #3. Would it be #1 instead?

> Clearly Rx's single-direction river of data(flow) in MVVM is an astronomical advance over, say, the oft-cited Callback Hell in MVC that basically become Big Ball of Mud software architecture in any significantly-complex app.

How would this work in the case of for a tree view?

> A background on callback-based VIPER & MVVM without Rx added:
> https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

OK.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de