Canvas wrappers: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎MFD: typo)
(Switch to {{flightgear source}} and {{flightgear url}} to fix the broken Gitorious links.)
(10 intermediate revisions by 2 users not shown)
Line 14: Line 14:


== 2D Instruments parser ==
== 2D Instruments parser ==
Also see [[Howto:Creating_fullscreen_Canvas_applications#Parsing_Instruments_and_Texture_Mapping]]
 
The 2D panel module will reimplement the existing 2D panel functionality in Canvas/Nasal space, so that the legacy C++ code can be slowly phased out:
 
{{cquote|<nowiki>I'm even more convinced now that we should move the 2D panel and HUD rendering
over to this approach, since that would get rid of all the legacy OpenGL code
besides the GUI.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37868.html|title=<nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>Tue, 24 Jul 2012 10:36:26 -0700</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}
 
<references/>
 
 
Also see [[Howto:Parsing 2D Instruments using the Canvas]]


We need to reimplement the 2D panel code in $FG_SRC/Cockpit/
We need to reimplement the 2D panel code in $FG_SRC/Cockpit/
* [https://gitorious.org/fg/flightgear/blobs/next/src/Cockpit/panel_io.cxx panel_io.cxx]
* {{flightgear source|src/Cockpit/panel_io.cxx|text=panel_io.cxx}}
* [https://gitorious.org/fg/flightgear/blobs/next/src/Cockpit/panel.cxx panel.cxx]
* {{flightgear source|src/Cockpit/panel.cxx|text=panel.cxx}}
* $FG_ROOT/Docs/README.xmlpanel
 
Note that the FGPanel code is a bit cleaner than the old code, i.e. see [{{flightgear url|src/Cockpit/panel.cxx|line=366}}].


Write a Nasal module that will take our existing instruments in $FG_AIRCRAFT/Instruments and turn them into canvases. Namely, that means, parsing:
Write a Nasal module that will take our existing instruments in $FG_AIRCRAFT/Instruments and turn them into canvases. Namely, that means, parsing:
Line 38: Line 51:


In fact, the combination of Nasal and the Canvas is so much more flexible than our existing panel code, that it is foreseeable that it will see useful additions, which is why it'd be a good idea to introduce an optional version tag, so that new instruments can directly use canvas features.
In fact, the combination of Nasal and the Canvas is so much more flexible than our existing panel code, that it is foreseeable that it will see useful additions, which is why it'd be a good idea to introduce an optional version tag, so that new instruments can directly use canvas features.
== GUI Widgets ==
There's a dedicated article at [[Canvas 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 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.
Also, we also don't need to duplicate the existing C++ code and the dialog XML parsing.
Everything keeps as working as it is, adding new widgets (and USING them) can be purely done by modifying stuff in the base package, without touching the C++ code again.
In order to start using any custom Canvas-widgets, you only need to change the widget type to "canvas" and specify the name of the widget to be instantiated. For example:
<syntaxhighlight lang="cpp">
<type>canvas</type>
<name>button</name>
</syntaxhighlight>
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)
For example, if someone creates a new Canvas-based widget, say a "button" - all that is needed to start using it in FG, would be modifying the corresponding GUI XML files, and replacing the
<syntaxhighlight lang="cpp">
<type>button</type>
</syntaxhighlight>
with this instead:
<syntaxhighlight lang="cpp">
<type>canvas</type>
<widget>button</widget>
</syntaxhighlight>
(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++.
== MFD ==
The MFD module will provide a wrapper on top of the canvas system specifically designed for building MFD-type displays (PFD, ND, EICAS etc). The MFD module will be largely based on the hard coded displays currently available in FlightGear, in particular the NavDisplay: [[Navigation display]]. What about CDUs, shall these be also covered by this module, or separately?
== 2D Panels ==
The 2D panel module will reimplement the existing 2D panel functionality in Canvas/Nasal space, so that the legacy C++ code can be slowly phased out:
<pre>
I'm even more convinced now that we should move the 2D panel and HUD rendering
over to this approach, since that would get rid of all the legacy OpenGL code
besides the GUI.
</pre>[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37868.html]

Revision as of 10:45, 9 March 2016


The canvas subsystem is entirely implemented on top of the property tree, so it does not depend on Nasal scripting. However, it is Nasal scripting which makes the Canvas system really flexible and powerful.

Currently, there are a number of efforts being discussed to unify the 2D rendering backends in FlightGear (2D panel, HUD, GUI etc) to ensure that the Canvas system is the common backend for all these needs, which will reduce the amount of legacy C++ code that we have in FlightGear for these things, while also paving the way towards better overall OpenGL compatibility, better maintainability and more optimization opportunities.

Directly working with the canvas via the property tree is possible but tedious, that's why there is a special generic Nasal wrapper to simplify working with canvases. However, to cater for more specific 2D drawing needs, there are going to be additional wrappers provided on top of the main canvas.nas module.

The purpose of this page is to determine the requirements for each wrapper.

HUDs

The HUD module will be specifically targeted at developing HUDs.

2D Instruments parser

The 2D panel module will reimplement the existing 2D panel functionality in Canvas/Nasal space, so that the legacy C++ code can be slowly phased out:

Cquote1.png I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.[1]
— James Turner
Cquote2.png
  1. James Turner (Tue, 24 Jul 2012 10:36:26 -0700). Re: [Flightgear-devel] Switching from PUI to osgWidget.


Also see Howto:Parsing 2D Instruments using the Canvas

We need to reimplement the 2D panel code in $FG_SRC/Cockpit/

Note that the FGPanel code is a bit cleaner than the old code, i.e. see [1].

Write a Nasal module that will take our existing instruments in $FG_AIRCRAFT/Instruments and turn them into canvases. Namely, that means, parsing:

  • params
  • layers
  • transformations
  • conditions
  • actions

Basically, we should already have all building blocks in place, because:

In fact, the combination of Nasal and the Canvas is so much more flexible than our existing panel code, that it is foreseeable that it will see useful additions, which is why it'd be a good idea to introduce an optional version tag, so that new instruments can directly use canvas features.