20,741
edits
Canvas Nasal/JavaScript Subset: Difference between revisions
Jump to navigation
Jump to search
m
Canvas Nasal/JavaScript Subset (view source)
Revision as of 15:01, 12 December 2014
, 12 December 2014→Background
m (→Background) |
m (→Background) |
||
| Line 17: | Line 17: | ||
One idea we discussed is to "compile" Nasal into Javascript and send it to the browser (together with the canvas as SVG), but we don't know yet if this is possible with a reasonable effort. Also we should ensure that the JavaScript API and Nasal API are identical, such the code can be easily converted/ported. So we need to define a safe subset of Nasal and JavaScript and come up with corresponding classes to wrap identical stuff. And there are a quite a few useful JS features that Nasal will never support, so we need to use factories for those to hide differences between both languages (sounds like something that Philosopher might enjoy), or someone will end up complaining that jQuery breaks Nasal... | One idea we discussed is to "compile" Nasal into Javascript and send it to the browser (together with the canvas as SVG), but we don't know yet if this is possible with a reasonable effort. Also we should ensure that the JavaScript API and Nasal API are identical, such the code can be easily converted/ported. So we need to define a safe subset of Nasal and JavaScript and come up with corresponding classes to wrap identical stuff. And there are a quite a few useful JS features that Nasal will never support, so we need to use factories for those to hide differences between both languages (sounds like something that Philosopher might enjoy), or someone will end up complaining that jQuery breaks Nasal... | ||
{{FGCquote | |||
|For the sake of completeness, you could also use a completely different approach suggested by TorstenD: the new integrated mongoose httpd and JavaScript/DHML to create an animated website and serve that via FG (which would have nothing to do with FlightGear's hardware-accelerated Canvas system) | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214982#p214982 | |||
|title=<nowiki>Re: Need to Create a Standalone PFD</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Fri Jul 18</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | {{FGCquote | ||
| I have uploaded a new free Android App in the Play Store. This time it is a NAV display for airliners. At the moment the App works with the Boeing 777 and Airbus 330 (Omega), but I will start adding support to other planes in the near future. Many details like fixes, nav aids, waypoints (up to 12) have been carefully implemented so that the App resembles as much fatefully as possible the Boeing NAV display. The modes APP,VOR,MAP, ARC views, etc. are controlled from the panel in flightgear. | | I have uploaded a new free Android App in the Play Store. This time it is a NAV display for airliners. At the moment the App works with the Boeing 777 and Airbus 330 (Omega), but I will start adding support to other planes in the near future. Many details like fixes, nav aids, waypoints (up to 12) have been carefully implemented so that the App resembles as much fatefully as possible the Boeing NAV display. The modes APP,VOR,MAP, ARC views, etc. are controlled from the panel in flightgear. | ||
| Line 50: | Line 58: | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
|date=<nowiki>Fri Dec 12</nowiki> | |date=<nowiki>Fri Dec 12</nowiki> | ||
}} | |||
}} | |||
{{FGCquote | |||
|For animations, it would make sense to come up with a subset of JavaScript and Nasal which wrappers to hide the differences between the browser and fgfs, i.e. by wrapping props.nas/maketimer and building an animation framework on top of this safe subset. That way, we could allow people to create MFDs/instruments in Inkscape and a restricted subset of JavaScript/Nasal, which would mean that we could collaborate and grow a shared library of instruments that would be useful to both "front-ends". | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=219119#p219119 | |||
|title=<nowiki>Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Sep 22</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|Understandably, all of this is still in a very early state, i.e. just being discussed currently - but it would obviously be great if we could work out a way to better collaborate, because ideally, we'd really become front-end agnostic, so that we can provide the infrastructure that would allow people to create MFDs/instruments using just SVGs and a subset of JavaScript/Nasal. Alternatively, we can dynamically rewrite a subset of Nasal code to turn it into valid JavaScript - e.g. props.nas would be mapped to your ported JavaScript props APIs. I am sufficiently familiar with both, JavaScript and Nasal, and both languages provide support for dynamically compiling program code at run-time - so we could just as well come up with a very limited "instrument animation markup" that is interpreted by roughly ~250 lines of Nasal code, and mapped to JavaScript or Nasal/Canvas animation logic respectively.<br/> | |||
<br/> | |||
I don't think this would necessarily be a lot of work, it's primarily a matter of agreeing that we want to support these use-cases in the mid-term.<br/> | |||
Also, serializing an existing Canvas to a SVG could be done by introducing a handful of wrappers for mapping Canvas elements back to valid SVG markup, we can certainly prototype that in scripting space (which is how svg parsing currently works already) - even though some more C++ hooks would definitely be possible. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=219119#p219119 | |||
|title=<nowiki>Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Sep 22</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|If we could manage to pull this off, there'd no longer be any disparity between both approaches, and they would be fully compatible - and people interested in either method could help grow the library of instrument. The only thing that we might want to explore sooner or later is serializing a Canvas to a raster image that can be served by mongoose - you already seem to have code serializing screen shots to an osg::Image, so we could use the same method to serve an arbitrary Canvas to a browser, which will be useful for more complex layers that cannot be easily represented using just scripting (no matter if it's JavaScript or Nasal). | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=219119#p219119 | |||
|title=<nowiki>Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Sep 22</nowiki> | |||
}} | }} | ||
}} | }} | ||