20,741
edits
Canvas wrappers: Difference between revisions
Jump to navigation
Jump to search
m
→GUI Widgets
m (→GUI Widgets) |
m (→GUI Widgets) |
||
| Line 31: | Line 31: | ||
This is fully supported by Nasal code, as well as XML files. | This is fully supported by Nasal code, as well as XML files. | ||
I would suggest to use the specified widget's name and instantiate a little Nasal class eventually, i.e. something like (using ctor/method chaining): | |||
<syntaxhighlight lang="php"> | |||
globals["widgets"].button.new().update(); | |||
</syntaxhighlight> | |||
(which would internally be derived from a "widget" super class (parent vector set up accordingly), which would ultimately make use of the canvas.nas module) | |||
Doing it this way will ensure that the Canvas/GUI layer is truly generic and doesn't make any hard coded assumptions - everything can be done in scripting land, like you described regarding the ANNO1404 system. | |||
Also, it will be easier/more intuitive to create new GUI XML files that way, i.e.: | |||
<type>canvas</type> | |||
<name>button</name> | |||
Basically, it would be possible to migrate existing GUI XML files to the canvas system just by doing two things: | |||
1) reimplementing the corresponding PUI control (i.e. BUTTON) via canvas (adding a new module to $FG_ROOT/widgets/button,nas) | |||
2) editing the GUI XML file to replace "button" with the canvas-button instead (which could obviously also be done in the C++ code eventually) | |||