187
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 12:43, 4 December 2010
, 4 December 2010→LCD screen abstraction
m (bottom up screen design) |
|||
| Line 111: | Line 111: | ||
In reference to the CDU screen description in [http://wiki.flightgear.org/index.php/Howto:_Development_of_the_CDU#Details_of_the_.28LCD.29_Screen]: You could obviously further partition the screen area into LEFT/RIGHT if you wanted to, so that you could address each region separately by writing to different properties. | In reference to the CDU screen description in [http://wiki.flightgear.org/index.php/Howto:_Development_of_the_CDU#Details_of_the_.28LCD.29_Screen]: You could obviously further partition the screen area into LEFT/RIGHT if you wanted to, so that you could address each region separately by writing to different properties. | ||
--[[User:Hooray|Hooray]] 23:10, 3 December 2010 (UTC) | --[[User:Hooray|Hooray]] 23:10, 3 December 2010 (UTC) | ||
This is exactly what I did with the A380 MCDU, as Hcc23 says you need to create the text object in XML, however as Horray says the contents of the text object is taken from the property tree. So in my MCDU where you select the runway, then SID/STAR and then any TRANSITION POINTS, I create 8 osg Text objects in the XML (opt00 - opt08) these are placed on the screen in the XML and are tied to /instrumentation/mcdu/opt[]. Then in my Nasal script (mcdu.nas) I set values to the opt[] properties based on which action you are currently performing. The A380 MCDU is a bit more complex to manage than the 747 or 777 CDU, as it works like a computer monitor, input fields and output text can appear anywhere on the screen, not in LED lines and columns. | |||
A generalised method to manage lines of text is something else I've been thinking about and I like a lot of what you two have been saying here. For example on the E/WD there is a sequence of checklists, these would be perfect for the method you are talking, in particular something like; | |||
var region = TextRegion.new(lines, width, "property-prefix"); | |||
region.append("new text"); | |||
region.replaceAt(index, "text"); | |||
region.clear(); | |||
region.appendStyled("text", "style"); | |||
region.replaceAtStyled(index, "text", "style"); | |||
var nextLine = region.currentLine(); | |||
so this would create a child array /lines[''lines''] under ''property-prefix'' and a internal counter (for append). In your animation XML, you just then need to tie the OSG Text object to each property in the array. | |||
[[User:Scotth1|Scotth1]] 12:43, 4 December 2010 (UTC) | |||