20,741
edits
m (→GUI Widgets) |
m (→GUI Widgets) |
||
Line 14: | Line 14: | ||
== GUI Widgets == | == GUI Widgets == | ||
We briefly talked about this previously, it would probably make sense to provide a basic infrastructure to allow people to create custom widgets and reuse those easily, so that there's less copy/paste of code needed. Similar to the canvas API wrapper. | |||
In other words: whenever someone comes up with a new widget, it could be generalized and then moved somewhere into $FG_ROOT/Nasal - so that widgets can be easily shared and reused by base package contributors. | |||
ok, let's think this through: | |||
Ideally, people would be able to create custom widgets in Nasal. For example a button, then put it in $FG_ROOT/Nasal/widgets/button.nas - so that such custom widgets would be available to the GUI subsystem by specifying: | |||
- type=canvas | |||
- widget-type=button (i.e. button.nas - button namespace, for which the method new() is invoked) | |||
The GUI subsystem would then check if a PUI widget is a canvas, and if it is, it would call the corresponding Nasal constructor - i.e. globals["widgets"].button.new() | |||
(Nasal sub modules all share the top level namespace, i.e. "widgets" in this case) | |||
The widget module will allow implementing custom GUI widgets using the Canvas system and Nasal, this will make it possible to re-implement existing PUI widgets as fully interactive "Nasal canvases", so that usage of PUI is increasingly reduced, facilitating phasing out of PUI eventually. | The widget module will allow implementing custom GUI widgets using the Canvas system and Nasal, this will make it possible to re-implement existing PUI widgets as fully interactive "Nasal canvases", so that usage of PUI is increasingly reduced, facilitating phasing out of PUI eventually. | ||