Re: Ada-Oriented GUI

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

On Tuesday, March 20, 2018 at 4:34:59 PM UTC-5, Randy Brukardt wrote:
> I can't speak to all such systems, but the above is definitely not true of 
> Windows Win32. The GUI can be on any thread that it likes, the restriction 
> is that one needs to use a single thread to create windows and receive 
> messages.

That is actually not quite true either.  A window can be created by any thread, but henceforth for that window that thread becomes the UI thread for that window.  Another window with overlapping lifetime can be created on any thread (including the prior window's UI thread), but henceforth for this new window whichever thread it was created on becomes the UI thread fro that window.  The default is for all windows to be created on the Main thread, for which a dispatcher is provided.  Other threads must establish their own dispatcher for Windows events, as it is not already provided on non-Main threads.

This becomes more pronounced in post-Win32/WoW •frameworks•, such as UWP (nee WinRT).  The underlying OS is still Win32-based, but Win32 is increasingly unutilized in modern Microsoft programming.  Nowadays instead of Win32, we access all Microsoft operating systems via frameworks that are derived from ATL/COM technology, presented as DLLs with .WinMD supplementary mark-up that is accessible to the CLR for the CLR-based managed-runtime languages (i.e., C#, F#, Visual Basic, C++/CLI) and accessible in translation to processor-native languages (i.e., C++/CX*, C++/WinRT**).

* C++/CX is C++/CLI reworked to not compile to bytecode, but using the same grafted-on “divided by” C#-esque language to access the DLLs-with-.winMD-markup.

** C++/WinRT is ISO standard C++ that uses a code generator to move much of what C++/CX does at runtime to access the DLLs-with-.winMD-markup to build-time, so that /CLI's & /CX's grafted-on “divided by” C#-esque language is no longer necessary to access the DLLs-with-.windMD-markup.

Because Win32 is increasingly obsolescent, let's look at precisely what I was mentioning above regarding back-end processing threads submitting subroutines to execute on the window's “contract” UI thread.  Note CoreDispatcher's RunAsync family of methods that do precisely what I mentioned originally:  “Invariably, nearly all modern GUI-equipped OSes have a execute-this-subroutine/lambda-on-the-main-thread call in the GUI framework.”  To handle the UWP/WinRT era since Windows 8, I should have defined the term “each window's contract UI thread” and then said that on Android, iOS, and MacOS the contract UI thread is absolutely limited to the main thread for all windows/views, and the path of least resistance on UWP/WinRT is for the main thread to be the sole contract UI thread for all windows.

https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Core.CoreDispatcher

> (Any thread can do other operations.) We took advantage of this in 
> the design of Claw, where there is a separate Ada task created solely for 
> the purpose of managing the GUI. On top of this we built a fairly 
> conventional OOP design where the GUI task dispatches to appropriate 
> subprograms. This allows Ada programs fairly free access to the GUI from any 
> task. (It also has the downside of bringing in tasking issues into any Claw 
> program, even if there aren't any explicit tasks.)
> 
> It would be easy for Jeff to build his GUI design on top of Win32,

I never said that it wouldn't be.  I was saying that rarely is a design tied to absolutely running nontrivial amounts of non-UI code on the Main thread.  Let's assume that the ID of Main thread is fixed as 0 or 1 is all OSes.  Very rarely is a design so incredibly fixated on running on the thread with that ID.  Most designs don't care that they are running code on thread whose ID is 17 instead of the initial/Main thread, as long as there exists a way to find thread 17 when absolutely necessary when executing code on non17 threads.  (But better designs would not make such demands.)  My devil's-advocate point is:  what on Earth is the big deal about this design flexibility to demand that UI processing be performed on one or more non-Main thread(s)?  If a design is fixated on this dubious axiom as a immovable-mountain requirement, then it absolutely is •never• portable to Android, iOS, and MacOS to name a few, where UI processing is absolutely limited to executing on the main thread in the modern frameworks (legacy antiques such as XQuartz and Carbon notwithstanding on Mac).