20,741
edits
Canvas sandbox: Difference between revisions
Jump to navigation
Jump to search
m
→CanvasNasal
m (→CanvasModel) |
m (→CanvasNasal) |
||
| Line 263: | Line 263: | ||
This is not directly a new element, it's just an abstract base class that can be used to register a factory of Nasal-space elements. While that may be considered problematic from a performance standpoint, the idea is to expose the CanvasElement interface to Nasal space, so that developers can more easily prototype new elements in scripting space, and register those with the main Canvas::Group manager. | This is not directly a new element, it's just an abstract base class that can be used to register a factory of Nasal-space elements. While that may be considered problematic from a performance standpoint, the idea is to expose the CanvasElement interface to Nasal space, so that developers can more easily prototype new elements in scripting space, and register those with the main Canvas::Group manager. | ||
Hopefully, this will allow developers to come up with features that are reusable and agnostic to the concrete use-case, as well as support independent instances and styling. Which are basically the main challenges Canvas adoption is seeing/causing in fgdata, i.e. tons of useful features that are highly specific to a single use case, without supporting other use-cases. | Hopefully, this will allow developers to come up with features that are reusable and agnostic to the concrete use-case, as well as support independent instances and styling. Which are basically the main challenges Canvas adoption is seeing/causing in fgdata, i.e. tons of useful features that are highly specific to a single use case, without supporting other use-cases. | ||
Preferably, developers would use inheritance, composition and aggregation to design their elements using a handful of sub-elements. | |||
The key thing here is that we want to ensure that the Canvas system, and OSG itself, know what an element is all about, without all this knowledge having to exist solely in scripting space. While it may seem ironic at first that moving the implementation of new elements to Nasal, all the internal handling logic would directly use the proper interface of Canvas::element | |||
Once new elements have been refined and once they are proven, they could be partially/completely re-implemented in native C++ code, without any of the front-end code having to be changed. | Once new elements have been refined and once they are proven, they could be partially/completely re-implemented in native C++ code, without any of the front-end code having to be changed. | ||