Ticket #160 (closed: fixed)
Add properties to Geometry components
| Reported by: | Nick Draper | Owned by: | Roman Tolchenov |
|---|---|---|---|
| Priority: | major | Milestone: | Iteration 14 |
| Component: | Keywords: | ||
| Cc: | Blocked By: | ||
| Blocking: | Tester: | Martyn Gigg |
Description (last modified by Nick Draper) (diff)
As discussed between Nick and Laurent on Monday 02/06/2008.
The properties need to be able to handle general data values such as chopper speed and angle, but also modifiers to the geometry such as position and rotation modifiers (to account for motors).
The values need to be accessible through the Geometry object, but must not themselves be stored within the instrument tree as we need to share the geometry structure between workspaces that may have different properties.
One possibility would be to have any geometry objects found by through a workspace to be a returned as a throw away object facade that holds a pointer to the object from the geometry tree and a pointer to the relevant properties. This class would only be instantiated from the various data on demand and by using a shared pointer disposed of when no longer needed.
I've thought this through a bit more and attached a couple of class diagrams. Broadly The workspace holds a Parameterized instrument, not an Instrument (although they share an IInstrument interface). The Parameterized Instrument is just a composition of the Instrument and a ParameterMap. When you ask a Parmaeterized Instrument for a component you will actually be given a ParameterisedComponent, the main difference is that the Parameterized component has a shared pointer to the ParameterMap. Within ParameterizedComponent the GetPos, getRelativePos and getRotation methods would be overloaded to check the ParameterMap for any modifications. Also the getParent function would be altered to return another Parameterized Component, allowing a full traversal up the tree.
Attachments
Change History
Changed 12 years ago by Nick Draper
- Attachment GeometryWithWorkspaceProperties-Current.jpg added
Changed 12 years ago by Nick Draper
- Attachment GeometryWithWorkspaceProperties-Plan.jpg added
Planned changes
comment:4 Changed 12 years ago by Nick Draper
- Owner Laurent Chapon deleted
- Milestone changed from Iteration 11 to Iteration 12
comment:10 Changed 12 years ago by Roman Tolchenov
comment:11 Changed 12 years ago by Roman Tolchenov
comment:12 Changed 12 years ago by Nick Draper
- Status changed from new to closed
- Resolution set to fixed
comment:13 Changed 6 years ago by Pete Peterson
Moving css declaration out of the extrahead section
Refs #160
Changeset: 31bb7f1692dfea8e101cd9820ba0e657a50faeff
comment:14 Changed 6 years ago by Pete Peterson
- Status changed from closed to verify
This is being verified as pull request #161.
comment:15 Changed 6 years ago by Martyn Gigg
- Status changed from verify to verifying
- Tester set to Martyn Gigg
comment:16 Changed 6 years ago by Martyn Gigg
jenkins, retest this please
comment:17 Changed 6 years ago by Martyn Gigg
jenkins, retest this please
comment:18 Changed 6 years ago by Martyn Gigg
- Status changed from verifying to closed
Merge pull request #161 from mantidproject/160/sphinx_template
Moving css declaration out of the extrahead section
Full changeset: efba415acea92df7a33a4b7cf420286c62b994c6
comment:19 Changed 6 years ago by Martyn Gigg
I built and looked at the changes locally and the css is now being included properly.
comment:20 Changed 6 years ago by Martyn Gigg
Merge pull request #161 from mantidproject/160/sphinx_template
Moving css declaration out of the extrahead section
Full changeset: efba415acea92df7a33a4b7cf420286c62b994c6
comment:21 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 1008
Current class structure