20,741
edits
Howto talk:Development of the CDU: Difference between revisions
Jump to navigation
Jump to search
Howto talk:Development of the CDU (view source)
Revision as of 22:29, 3 December 2010
, 3 December 2010→LCD screen abstraction
| Line 88: | Line 88: | ||
--[[User:Hcc23|Hcc23]] 21:03, 3 December 2010 (UTC) | --[[User:Hcc23|Hcc23]] 21:03, 3 December 2010 (UTC) | ||
Most XML files (certainly the PropertyList files) in FlightGear will at some point be read into the property tree, where XML tags become properties. Depending on the subsystem, there is support for "live" properties, so that setting or overwriting a value in the property tree also affects the underlying system. Other properties are polled at framerate in the C++ code, so that modifying them also causes updates. | |||
Increasingly, properties are bound to listeners in the C++ code - so that systems can be updated like this, just by setting a property. You can see this in various parts: README.osgtext, for example, mentions support for properties in the form of "text-value" and "number-value" types, where the the value is not literal/hard coded in the XML file, but instead dynamically read from a property in the global property tree. This in itself, would make it possible to define a screen area and then use Nasal and the property tree to change the contents of the "LCD screen". So if you want to update some text on the "screen", this only means setting a property in the property tree by using Nasal (setprop). This way it would for example be possible to define a screen region with 14 lines by using 14 different INPUT properties. You could use a Nasal helper routine to ensure that there are not more than 24 characters written to each property (line), so that you simulate 14 lines X 24 columns. Due to the property tree and Nasal, there are lots of cases in FlightGear where Nasal sort of implicitly follows the MVC pattern already. So the representation and implementation of the screen logics could very well be separated like this. This would also mean that the XML file implementing the screen region, would not need to know about the high level stuff (i.e. CDU implementation), it would just be a "text area" that is populated with text from 14 different properties. | |||
Obviously, not everything can currently be implemented directly in Nasal space. But there are usually feasible workarounds available. | |||
For example, as far as I know, there is currently no support for also changing other font settings (font, font size, color, reverse) dynamically. But these would be fairly simple C++ modifications. The GUI system implements many of these features already. | |||
The general idea really is that the property tree is the mechanism to share data and communicate with other parts of FlightGear. If you really wanted to, you could even dynamically add 3D models by using Nasal. | |||
--[[User:Hooray|Hooray]] 22:29, 3 December 2010 (UTC) | |||
= XML conditions remark = | = XML conditions remark = | ||