Widgets Working Group
Taxonomy Attribute Model (alpha)

Description

The Interaction attribute(s) tell(s) us how (if) a user interacts with the widget. We make no assumptions about the input device(s) used except that it has an activator of some sort (whatever would generate a touchTime in a TouchSensor) that can be activated and released with or without movement in between. We use terminology applicable to a mouse (click, hold, drag) with the assumption that similar functionality will be provided by any input device that can interact with the various geometry-associated *Sensor nodes (i.e. CylinderSensor, PlaneSensor, SphereSensor, and TouchSensor). There may be more than one way a user can interact with a particular widget, of course. A 2D example is a scrollbar. One can drag the thumb or one can click to either side of the thumb or one can click and hold on either side of the thumb. Each of these is a separate type of interaction and, therefore, would warrant a separate Interaction attribute.

It is debatable whether None should be an allowed value for Interaction. The argument against is that if the user can't interact with the widget it isn't a widget at all. The argument for is the 2D example of a text label, which is always considered a widget in any windowing toolkit but does not change its text (directly) due to user action. So is a text label a widget or isn't it? How about a widget that takes an SFFloat or SFInt32 eventIn and displays the string representation of the number value of the event in a Text node?

The Selection attribute tells us whether the widget provides single selection analogous to radio buttons or a menu, multiple selection analogous to checkboxes or a multi-select list, or no selection functionality.

The Result attribute(s) tell(s) us what happens when this widget does something. There must be a result of some sort or it isn't a widget, after all. Something must be displayed (i.e. a change in the rendered scene), or an eventOut generated due to either user interaction or an eventIn. There can, of course, be more than one resulting output (event or scene graph change) for any given cause (eventIn or user interaction), and each one will be a separate Results attribute.

Note that this model makes no effort to link cause to effect, nor is it concerned with eventIns a widget may support. This may be an issue in the future.

Widget Attributes

Interaction >0	None
	Click
	Hold
	Drag	1D
		2D
		3D
Selection =1	None
	Single
	Multiple
Result >0	eventOut Attributes Value Constraints None Upper Lower Both Value Domain Continuous Discrete Discrete Set	single-field	SFBool
			SFColor
			SFFloat
			SFImage
			SFInt32
			SFNode
			SFRotation
			SFString
			SFTime
			SFVec2f
			SFVec3f
		multi-field	MFColor
			MFInt32
			MFNode
			MFRotation
			MFString
			MFVec2f
			MFVec3f
	Scene Graph	Geometry	Text
		Transformation	Translation
			Rotation
			Scale