20,741
edits
Howto talk:Development of the CDU: Difference between revisions
Jump to navigation
Jump to search
m
Howto talk:Development of the CDU (view source)
Revision as of 01:49, 4 December 2010
, 4 December 2010bottom up screen design
m (→Generality of the CDU: consider component model) |
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) | ||
== Bottom up design for virtual screen implementation (params) == | |||
Using XML parameters, it would for example be possible to develop a fully property driven virtual screen like this: | |||
* create an osgText animation file for drawing a single character from a property (property-char.xml) | |||
* create an XML file "property-line.xml" for assembling a line of n property-driven XML characters by including and parameterizing the "property-char.xml" file for a given width (24) and a certain offset (spacing) in between characters | |||
* create another XML file "property-screen.xml" for assembling an area of n lines (14) with "property-line.xml" included | |||
So for a 14x24 screen you would end up with 14x24 different properties to address the screen on a character-basis. | |||
The higher level XML files would obviously be able to customize/override any defaults (such as font, font size, color etc) used by the lower level files by using "params". | |||
To display strings on the virtual screen, one would then merely need to set each character property to the corresponding character, this could be done by a Nasal wrapper which takes a whole string as input and writes to the correct character property. | |||
While this would have some restrictions, it would be more flexible than a purely XML based solution: what is getting rendered is not determined by the XML files, these just determine the properties that are used for getting the character data. | |||
--[[User:Hooray|Hooray]] 01:49, 4 December 2010 (UTC) | |||
= XML conditions remark = | = XML conditions remark = | ||