Canvas wrappers: Difference between revisions

Jump to navigation Jump to search
m
Link to special directory articles
m (Link to special directory articles)
Line 16: Line 16:
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.
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.
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:
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:  
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
* type=canvas
Line 30: Line 30:
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.


The Canvas/GUI integration is implemented such that none of the existing code is touched, i.e. the old behavior remains fully supported. In addition, new widgets can be shared and reused by adding them to the $FG_ROOT/Nasal directory.
The Canvas/GUI integration is implemented such that none of the existing code is touched, i.e. the old behavior remains fully supported. In addition, new widgets can be shared and reused by adding them to the [[$FG_ROOT]]/Nasal directory.




Line 62: Line 62:


Basically, it would be possible to migrate existing GUI XML files to the canvas system just by doing two things:
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)
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)
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)


Line 81: Line 81:
(i.e. rename type and add a new "widget" node)
(i.e. rename type and add a new "widget" node)


This can be done automatically within seconds using XSLT for XML files in $FG_ROOT - and all of a sudden, the PUI button class would no longer be used - no need to touch any C++.
This can be done automatically within seconds using XSLT for XML files in [[$FG_ROOT]] - and all of a sudden, the PUI button class would no longer be used - no need to touch any C++.


== MFD ==
== MFD ==

Navigation menu