Canvas wrappers: Difference between revisions

Jump to navigation Jump to search
m
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.


Navigation menu