Angora

A GUI framework implemented as a concurrent window system in Go.

Building upon the ideas presented in the white paper "A Concurrent Window System" by Rob Pike (1989?), Angora is an attempt to update the model and create a GUI framework based upon it for use in current Go desktop applications running on popular operating systems.  One significant departure from the ACWS model is a re-examination of the role of events.

When the ACWS paper was written, graphical user interfaces were barely out of the lab.  The user base of GUI's today is at least a million times larger than it was then and the nature of the user population is very different.  There are no clean separations to be made between keyboard, mouse, touch-screen, voice recognition, game controllers, and other human input devices.  There are, however, two basic forms of human input; namely data and control.  Data input is the entering of some form of data to be processed, stored, sent; in some way used by the process.  Control input is input which controls the process, including control input which manipulates data or data flow.  It is, in simple terms, the difference between retyping a paragraph and using cut and paste.

Given present operating systems, an event system is already tied to at least the main window of an application.  There is no choice at the GUI framework level of whether or not to work with a platform supplied event stream.  The most common model in use today ties together the attributes of a window, a main entry point, and a main event message handler all in one lump and largely constrains it to conducting at least display operations in one thread of execution.  Simplifying, the Angora uses a  model which views the interface with a platform's windowing system as three distinct interfaces; event input, event output, and display output.  A further simplification is to treat all three interfaces as being non-reentrant and tied to a specific 'main' thread.

Angora considers each of these interfaces to be a separate channel of communications.  These channels are then subdivided further.  For example, Angora subdivides the event input channel into a supervisory input channel, a data input channel, and a process control channel.  The output event channel is fairly simple, just enough to meet the requirements of the underlying system, mainly movement and state related.  The display output channel is potentially much more complex and seemingly a bottleneck for concurrency, or is it?

What if the display output channel is treated simply as a data pipe that provides and updates the minimum data necessary for a presentation?  Regardless of the actual implementation of the display interface, a window in Angora need only supply enough data to initialize the representation and then to notify the representer of any changes to the representation.  The presentation layer is entirely decoupled from the window except for that single channel.  The presentation layer could be as simple as a bitmap renderer, as complex as an OpenGL text renderer, or even as involved as DX11 animated model rendering engine.

Revisiting input events for a moment.  While the desirable simplicity of the ACWS paper's K(keyboard) and M(mouse) do not seem to be directly achievable, at least in the Angora model, there is an approach by which some of that simplicity and directness may be recovered.  If the event input channel is viewed as a pipe, it is conceivable to provide filters and multiplexers to that pipe.  The initial ones are assumed to be embedded in the interface to the platform and provide the separation of supervisory, data input, and process control channels.  Specialized filters could then be created to further subdivide those, simplifying the implementation of various child windows or widgets.

At this point, the reader is encouraged to take a break and revisit Rob Pike's "A Concurrent Window System" white paper.

Status:

Currently under design.