Howto:Prototyping a new NavDisplay Style: Difference between revisions

Howto:Prototyping a new NavDisplay Style (view source)

1 byte added , 26 October 2016

20,741

edits

@@ Line 63: / Line 63: @@
-This "handle" is not just read-only, i.e. you get a mutable handy, which means you can traverse the tree and query it (e.g. to locate certain elements) and then freely add/remove or rename/duplicate elements, using the exact same APIs used to manipulate the global proeprty tree (e.g. props.nas).
+This "handle" is not just read-only, i.e. you get a mutable handle, which means you can traverse the tree and query it (e.g. to locate certain elements) and then freely add/remove or rename/duplicate elements, using the exact same APIs used to manipulate the global proeprty tree (e.g. props.nas).
 And that is basically answering your question: The XML file posted in the wiki is incomplete - it would not make any sense at all without the embedded Nasal portions, but it contains a few redundant nodes that are not recognied by the existing GUI engine.
 However, nasal/open block will specifically look for these redundant blocks and treat those as "templates" for certain widgets, e.g. those requiring dynamic contents (think a list of known styles, which cannot be hard-coded, think a list of MAP modes, ranges etc).