20,741
edits
Talk:CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 46: | Line 46: | ||
If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST) | If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST) | ||
<hr> | |||
SviewCreate() already understands much of conventional <view> specifications so that it can clone the current view. At some point we might want to introduce a new way of specifying views that can better make use of Sview's flexibilities compared to conventional views, e.g. with an alternative <sview> tag or similar. | |||
But we might want to specify extra things such as customised heading/pitch/roll/zoom values etc. If we required the caller to add these extra things to the <view> specification, then the caller would have to either pollute the global /sim/view[]/ tree or copy it into a temporary tree and add in the required custom values. | |||
So i wonder whether, rather than taking a single SGPropertyNode*, SviewCreate() should instead take a std::vector of SGPropertyNode*'s which it treats as a kind of union of trees. When the sview code looks for a particular tag such as z-offset-m, it would look in each SGPropertyNode* in turn until it finds a match. Thus the caller can override aspects of the default view by specifying an extra tree at the start of the list. | |||
However if we think it's ok to require the caller (e.g. Nasal code) to modify a copy of a global /sim/view[]/ tree, then tree unions are not necessary. This would probably be conceptually simpler too. | |||
Either way, i'll can try to implement something in next this weekend so that people can try things out soon. | |||
--[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 19:17, 4 December 2020 (EST) | |||
<hr> | |||
:: That sounds very much like the way Nasal's "multiple-inheritance" mechanism is internally implemented (it traversing a vector named "parents") - while it sounds indeed very powerful, it seems like overkill at this point ? Personally, I'd opt for a simple "version" argument for views (XML + property level) - so that new features can be easily added without breaking anything, if aircraft devs want to use those, it's not too much specify a corresponding <code><version>112</version></code> tag or a corresponding props.Node and increment the version number whenever breaking changes are made to sview, while posting an announcement to the devel list. That would also mean that scripts could be provided to update -set.xml files automatically.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:59, 4 December 2020 (EST) | |||