Talk:CompositeViewer support: Difference between revisions

Jump to navigation Jump to search
m
Line 19: Line 19:
Note that this isn't intended to be a/the definite UI - but rather a simple way to set up views using a GUI, so that people (early-adopters) can more easily experiment with these features, and hopefully also help with wider testing and provide better bug reports along the way.
Note that this isn't intended to be a/the definite UI - but rather a simple way to set up views using a GUI, so that people (early-adopters) can more easily experiment with these features, and hopefully also help with wider testing and provide better bug reports along the way.


While it would obviously be possible to create a fancy Nasal (cppbind) or C++ specific API, I have come to the conclusion that it makes sense to go '''only''' through the <code>fgcommand</code> layer, passing a SGPropertyNode/props.Node structure with key/value pairs.
While it would obviously be possible to create a fancy Nasal (cppbind) or C++ specific API, I have come to the conclusion that it makes sense to go '''only''' through the <code>fgcommand</code> layer, passing a SGPropertyNode/props.Node structure with key/value pairs:
 
<syntaxhighlight lang="javascript">
fgcommand("composite-viewer-create", props.Node.new({
 
}));
 
</syntaxhighlight>


That way, we can trivially support PropertyList/XML files, but also views that are specified directly, as part of a sub-tree (e.g. for the CanvasView element).
That way, we can trivially support PropertyList/XML files, but also views that are specified directly, as part of a sub-tree (e.g. for the CanvasView element).

Navigation menu