UI Design

This is a proposition for a scriptable UI system. Leave any comments you have underneath the paragraph in question. Use a colon (or more) to indent your comments.

Note: I have not yet researched how this would be implemented, so some of the design may need to be changed.

Objects
Two kinds of objects will be available: Primitives and objects derived from them. The difference between the two is that primitives handle their own rendering and will most likely be coded in Java, while the derived objects are likely to be coded in the scripting language and will essentially be a collection of primitives.

Primitives
The intent is to have as few primitives as possible, and derive other objects from them. For example, instead of making a button a primitive, it could be derived from a frame.

Primitives will be:
 * Frame: The main and most common object in the UI. Properties include texture, color (including alpha), size, etc. Handles events. May contain children.


 * Text: Just some text. Properties include color, location and size. May not contain child objects.

Frames will handle the bulk of UI events. A main frame (let's call it UIRoot) will receive events directly from the event loop, and pass them to child frames and objects if necessary. Each child frame then passes events to its children if necessary, and so on.

Derived Objects
These will be custom defined objects that define a bunch of primitives. A Button for example would define a Frame and a Text object, and handle the logic for changing the button's texture and calling event handlers if the button is enabled/disable etc.

Events
As mentioned earlier, UIRoot receives events directly from the event loop. UIRoot receives all events, then passes them to child frames if they are eligible. For example, it would pass click events to the topmost frame under the cursor, or keyboard events to the frame with focus, etc.

Frames will have a list of event handlers for each event. Even basic functionality such as passing events to child frames will be handled by a default handler contained in this list. By raising an exception, a handler can prevent the execution of other handlers. This provides maximum flexibility, as the user can override default handlers, change the order in which they are called, or remove them entirely.

Sandboxing
The UI scripts should (must) be sandboxed to prevent access to disk or other system calls such as exec. In addition, any API calls that request information from the server will pass through the client for throttling purposes. (Of course, the server must still have a mechanism to protect against flooding)

= Comments =

We will use Swing skinned with the Synth skin for the UI, so this approach is a bit too low level. We may want to expose some higher level widgets to the UI Designer, such as action buttons, input fields, lists, tables, inventories, message list windows, input lines, tabbed views, dockable panels, design editors, etc. I agree with you on composite widgets though - users should be able to create their own widgets by combining existing ones.

I think we can get a relatively long way without any scripting support also, just allowing the UI designers to hook up the inputs and outputs of the widgets to action and perception channels going and coming from the avatar or controlled entity (any controllable entity should be able to provide its own user interface, that is nicely sandboxed).

If we do support a scripting language, we could either pick something existing that can be sandboxed (the scripting code can come from other users or the server, so it should not be allowed to access the system freely, just the game object it is allowed to control), or we could perhaps use a visual scripting language both for client scripting and for creating scripts that can run on the server (to control some in-game object or the avatar).

-- zzorn 2007-09-09