Technical Meeting 05/04/2006 1:15PM EDT
Agenda
| Item | People | Description |
|---|---|---|
| 1 | Geveci | Accept/Reset/Undo/Redo Blues |
| 2 | Geveci | 3D Widgets |
| 3 | Ayachit | Undo/Redo. |
| 4 | Geveci | Memory leaks |
Action Items
- Geveci - Explore the feasibility of providing additional "high-level" metadata to the UI layer so that 3D widgets can be automatically generated based on property types.
- Stimpson - Author a wiki page describing how custom object inspectors are created and deployed.
- Stimpson - Propose an API for connecting 3D widgets to the user interface.
- Ayachit - Update the server-manager undo/redo implementation to ensure that state change recording are automatically routed to the correct undo stack based on connection.
- Ayachit - In Mark's absence, work on undo/redo-enabling proxy creation and deletion.
- Shead - Work on failing test cases.
Discussion
Berk discussed the complexity of making connections among the UI, proxies, and 3D widgets. A typical example would be a "Cut" filter where there are three objects involved: the cut filter itself, an implicit plane (or similar filter) that is an input to the cut filter, and a 3D plane widget which must be "connected" to properties on the implicit plane. From a user perspective the cut filter is what is explicitly created, the other two must be created and managed in code. Presumably, the implicit plane is created and connected to the cut filter by the UI layer at the time the cut filter is created. The requirement to create an implicit plane could be handled by special-case code based on the type of filter (cut) being instantiated, or (better) by examining the domain of the cut filter properties. Creation of the 3D widget is an orthogonal issue, since the 3D widget would presumably be created / destroyed based on whether the user has opened the object inspector for the cut filter. There are two proposals on how to manage 3D widget creation: first (and easiest) would be to simply require that filters requiring 3D widgets have a custom object inspector. The custom inspector code would be responsible for managing 3D widgets. The second alternative would be to improve the typing of properties by providing metadata to describe the semantics of a property. As an example, the additional metadata would make it possible to distinguish a point property from a vector property, even though both share the same internal representation. In the case of an implicit plane, such metadata would provide a hint to the UI that the point and direction properties collectively describe a plane, allowing the UI to automatically create a plane widget and connect it.
