Concepts

A GUI framework must enable input and output to many devices of the same class without requiring recompilation. It must support transformation of dynamic information.

A GUI framework should enable interaction with many classes of devices. It should be optimised to common contemporary classes of devices. Examples of devices:

• LED—output in the dimension boolean.
• Button—input in the dimension boolean.
• Keyboard—input in the dimension character–set.
• VoltMeter—output in the dimension voltage.
• Rheostat—input in the dimension voltage.
• Mouse—input in the dimensions x, y, boolean, at least.
• 3D Mouse—input in the dimensions x, y, z, boolean.
• Monochrome monitor—output in the dimensions x, y and intensity.
• Colour monitor—output in the dimensions x, y, hue, intensity, saturation.
• Clock—output in the dimension t.
• Animation—output in the dimensions x, y, z, t, hue, intensity, saturation.
• Viola—output in the dimensions intensity, screech.
• Digital theremin—input in the dimensions x, y, z.

A UI library should enable sophisticated output. It must enable input on that sophisticated output. As an example, consider M–theory. “We still don’t know what the fundamental theory behind string theory is, but judging from all of these relationships, it must be a very interesting and rich theory, one where distance scales, coupling strengths and even the number of dimensions in spacetime are not fixed concepts but fluid entities that shift with our point of view.” [Basic String Theory]

M–Theory can resolve to 26 dimensions of spacetime; 10 or 11 dimensions are currently expected. A number of M–theory variants require multiple dimensions of time. Time in a framework can be just another dimension, such as in a simulation, or, in that rather important special case, can be real world time.

A framework should permit efficient expression of sophisticated geometric concepts. It should enable easy expression of common contemporary practice.

An ex–Windows and an ax–Apple designer discuss the future of the user interface: “Looking to the future, both Mr. Ratzlaff and Mr. Ligameri agree that operating system user interface design is moving away from a windowing system as content consumption replaces content creation as the primary use for a computer. Witness, for example, Windows Media Center Edition or Apple’s Front Row software, which do away with dialog boxes, menus, and buttons. Your cell phone’s interface, or even any of Apple’s iLife applications, are similar examples.” [Mac Observer]

A framework should not be tied to a particular methodology of user interface design. It should enable efficient usage of common contemporary practice.

• Dimension—a scalar type (as per MPL).
• Brane—A surface of zero or more Dimensions, e.g. a point, a string, a sheet, a volume, etc..
• Border—A brane with an external connection to, say, a device.
• Coordinate—Each coordinate uniquely defines a Brane cell; every Brane cell has a unique coordinate.
• Coupling—A connection between brane(s) and/or border(s). A coupling can translate, for example, scalar values along and between dimensions. It can also serve more traditional forms of communication. A brane can use a coupling to prod another (an event), a brane use a coupling to sense a state in another (such as current mouse position).
• Property—Something processed by a brane or coupling that is not a dimension. For example, a graphics brane might process fog, which affects relative appearance of items in the brane from elsewhere in the brane. A screen border might process font.

Many borders have dimensions with fixed value minima and maxima. Other have limits and properties determined at runtime. This suggests that fixed dimension branes, with simple couplings, can have those couplings highly optimised so long as the framework is structured correctly, but that branes must not be limited to the fixed. The design must support both, with the intention of making conversion from variable to fixed effective.

Many classes of devices have common functionality. This suggests that, with properly designed templates, calls to functions which are implemented on borders can be passed directly to those devices. The combination of fixed dimensions, simple couplings, and template specialisation, should mean that calls to functions directly implemented on a device can lead to significant optimisations. This, however, requires the gui framework to support functions which are hardware implemented on many devices. The problem is that a generic software implementation needs to be constructed for those functions not implemented on a device (I suggest this is a vendor problem; if the vendor does not support a particular feature, even through emulation, it’s not the library’s job to supply an alternative implementation; rather, it’s the library’s job to enable independent access to used features). There is a conflict between defining many function and few functions. On the other hand, if a border does not support a property, the coupling to that border can translate it by ignoring it.

Many common GUI frameworks are written in terms of function calls; output via a function call in an framework, input via a function call from the framework, even though the underlying OS API may use messages for input. The framework must not be tied to a particular approach, but must support the various approaches used by different operating systems effectively.

Contemporary display hardware offers exceptional power relative to the features available in many gui frameworks. A standard framework must not hinder efficient access to such hardware, particular since advances in display hardware are likely to continue.

An application makes a call to a brane. A coupling may translate that call into corresponding calls in coupled branes. This may result in output to a border, a call in an application, a change in the state of a brane, or combinations of these (including nothing happens). A border makes a call to a brane (perhaps it’s picks up an API event, and pretends it’s been called). A coupling may translate that call into corresponding calls in coupled branes. This may result in output to a device, a call in an application, a change in the state of a brane, or any combinations of these (including nothing happens).

Thus, using boost graph terminology, a brane is a dynamic n–dimensional graph of couplings.

2006