Re: Ada-Oriented GUI

["Dan'l Miller" <optikos@verizon.net>]

On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote:
> Those interested can find Ada_GUI at
> 
> https://github.com/jrcarter/Ada_GUI

“… a better design for a GUI is for the GUI to have its own task, so it doesn't require that its client give up a thread of control. GUI events are communicated to the client through a protected queue of events. The client software can be written in the clearest way possible, unconstrained by the GUI.”

Although I am sympathetic to your goals* in general, please allow me to play devil's advocate for the current status quo thread design in nearly all GUI-equipped OSes.  The GUI does in fact have its own thread:  the main thread of the process.  The “client software can be written in the clearest way possible, unconstrained by the GUI” by executing on one or more threads other than the main thread.  These other threads may be of any design imaginable (other than being the main thread).

* One laudable goal is your de-emphasizing/eliminating of subroutine invocation on the main thread.  In most modern app designs, nearly all processing that is not highly-tied to the GUI is performed on additional threads other than the main thread.  But invariably the final stage of processing is to do something that delivers the results to the GUI executing on the main thread.  Invariably, nearly all modern GUI-equipped OSes have a execute-this-subroutine/lambda-on-the-main-thread call in the GUI framework.  This is silly over-emphasis on subroutines, when an interthread message queue (from the backend-processing threads to the GUI thread) would be the superior design.  Asynchronous subroutine invocations from the GUI on the main thread (with this concomitant increase in callbacks contributing to Callback Hell) is yet another dubious ‘innovation’ needed to work around the lack of a message-queue-based GUI; one gets async for free implicitly with message-queue-based designs.

> Those who like programming by extension won't like it.

No programming by extension?  I'd say that you just haven't gone far enough down that message-based design road yet:  Note that tag-length-value (TLV) has been successfully utilized for decades throughout many IETF message formats to provide programming-by-extension-esque capabilities to message-queue-/messaging-based systems, when operating under the proviso that any tag that the recipient does not recognize is to be ignored due to being from a subsequent/newer release of software.  Hence, programming-by-extension(-via-OO-methods-as-subroutine-invocations) as commonly conceived is not entirely incompatible with messages in a message-queue-based system.  The focus changes from subroutine invocation to ignoring TLVs in recipients equipped with older/less-featured software and processing those feature-added TLVs in recipients equipped with newer/more-full-featured software.  The mechanism of programming by extension merely changes; the concept itself does not.