Canvas PUI mapping: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
{{Stub}}
{{Stub}}


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.
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.


columns: directive/tag, progress, priority, remarks
columns: directive/tag, description, progress, priority, remarks


The basic idea can be seen below:
The basic idea can be seen below:

Revision as of 17:00, 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.

columns: directive/tag, description, progress, priority, remarks

The basic idea can be seen below:


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