Canvas PUI mapping: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 12: Line 12:
|-
|-
| {{tag|property}}, {{tag|format}} || formats properties ||  high || {{Progressbar|60}} || working proof-of-concept
| {{tag|property}}, {{tag|format}} || formats properties ||  high || {{Progressbar|60}} || working proof-of-concept
|-
|-
| {{tag|enable}}, {{tag|visible}} || enables/disables and hides/shows widgets dynamically ||  high || n/a || still to be done
|-
|-



Revision as of 19:11, 9 July 2016

This article is a stub. You can help the wiki by expanding it.

this will become a table with the most essential PUI directives (non-widgets), such as layout/styling and common PUI widget functionality (think live properties, bindings, conditions), so that we can keep track of what's missing/needed and finished already.


The basic idea can be seen below:


tag/directive description priority progress remarks
<property>, <format> formats properties high 60}% completed working proof-of-concept
<enable>, <visible> enables/disables and hides/shows widgets dynamically high n/a still to be done


We will need to come up with some kind of "adapter" class that maps common PUI functionality to arbitrary Canvas widgets, specifically:

  • <height> and <width>
  • <legend> <label>
  • <property> and <format>
  • <binding>
  • <default>
  • <enable>
  • <visible> (easy)
  • <keynum> and <key>
  • <font>
  • <color>


Currently, this is accomplished in non-generic, fairly roundabout, fashion in the applyPUIAttributes() helper funciton in the pui2canvas parser