20,741
edits
Talk:CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
Talk:CompositeViewer support (view source)
Revision as of 14:19, 30 November 2020
, 30 November 2020→View Creation API
| Line 31: | Line 31: | ||
The low-level implementation would expect a corresponding SGPropertyNode structure, a higher level fgcommand could then provide an "option" or a "mode" to either specify an XML file on disk, or a property tree branch that already contains the required nodes. That way, the back-end would look the same, and we would only need to call readProperties() first whenever people want to use a file-based view declaration. | The low-level implementation would expect a corresponding SGPropertyNode structure, a higher level fgcommand could then provide an "option" or a "mode" to either specify an XML file on disk, or a property tree branch that already contains the required nodes. That way, the back-end would look the same, and we would only need to call readProperties() first whenever people want to use a file-based view declaration. | ||
For the CanvasView scenario, that would mean that the CanvasView element would merely replicate/alias properties used by the CompositeViewer/Compositor systems, so that each element would get a property-based handle to the relevant modules. | |||
Besides, this means that '''any''' UI/frontend can invoke the corresponding back-end code easily: | Besides, this means that '''any''' UI/frontend can invoke the corresponding back-end code easily: | ||