8,564
edits
FlightGear Newsletter June 2014: Difference between revisions
Jump to navigation
Jump to search
Remove empty sections, turn Cquotes into text, remove copy of Howto:Creating a Canvas GUI dialog file
m (add content as per Gijs' request) |
(Remove empty sections, turn Cquotes into text, remove copy of Howto:Creating a Canvas GUI dialog file) |
||
| Line 93: | Line 93: | ||
}} | }} | ||
{{Newsletter-article-start|Boeing 777 EFB prototype|By [[User:I-NEMO|I-NEMO]]}} | |||
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]] | [[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]] | ||
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]] | [[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]] | ||
| Line 160: | Line 99: | ||
I-NEMO has started porting his 777/EFB prototype to [[Canvas]] | I-NEMO has started porting his 777/EFB prototype to [[Canvas]] | ||
As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind: | |||
# do something to compensate for the lacking of an EFB inside the Boeing 777 Seattle. | |||
# actually try (I repeat it: 'try') to learn some first essentials of nasal. | |||
This Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit. I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works... | |||
Current development ('modernisation' phase) of the '''Boeing 777 Seattle's EFB''' is going on nicely; the code is shorter, more readable and cleaner. | |||
I have not finished it, yet (I'd say that it's almost 50% done). | I have not finished it, yet (I'd say that it's almost 50% done). | ||
At the moment I have a single Canvas group (i.e., ''EFB_group''), with 5 children: the text-matrix (16 left lines, 16 right lines), a Title line , an Helper line and the Display.<br/> | |||
The ''Display'' element is then textured with all the various pages' textures, called by the page-handler (''see'' here below).<br/> | The ''Display'' element is then textured with all the various pages' textures, called by the page-handler (''see'' here below).<br/> | ||
Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays. | Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays. | ||
that's the <u>current status</u> of the new 777 ''Seattle'''s EFB: it's still far from being perfect, but - as a newbie - I'm quite satisfied for the moment: I need to finish the first version fairly soon, because my to-do-list is long (I have to re-model all the aircraft fuselage [original model has wrong measures, ''sigh!''], produce better gears and flight-control surfaces model & animations in Blender, and then to produce a new Paint-Kit in Photoshop; then all 3D models optimizations...and so forth; of course, we also have to take care of CDU, which will interface with the EFB. So, the job is still very, very long... | |||
The current EFB code is heavily focused on rendering raster images, which can be retained obviously, but in FG, we have additional means to render airport information that is 100% in sync with the FG side of things (navdb). <br/> | |||
<br/> | <br/> | ||
For instance, we are going to "port" the airport-selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: [[Canvas_MapStructure#Porting_the_airports.xml_dialog]] <br/> | For instance, we are going to "port" the airport-selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: [[Canvas_MapStructure#Porting_the_airports.xml_dialog]] <br/> | ||
| Line 235: | Line 122: | ||
<br/> | <br/> | ||
As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access [http://airnav.com http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison. | As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access [http://airnav.com http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison. | ||
Learn more at [[Canvas EFB Framework]] or follow the [http://forum.flightgear.org/viewtopic.php?f=71&t=23204 forum discussion]... | |||
{{Newsletter-article-start|Towards an Aircraft-agnostic MFD Framework|By [[User:Hooray|Hooray]]}} | |||
Given the recent trend of having several MFD-related efforts without any kind of collaboration/code reuse going on here among our contributors (PFD, ND, Avidyne Entegra R9, EFB), I have started prototyping a generic MFD framework that is purely XML-based, inspired by discussions we've had over the last couple of weeks, and lessons learnt from the missions subsystem. | |||
It is intended to: | |||
* support multiple independent instances | |||
* be totally aircraft agnostic | |||
* support a pure dialog-driven mode | |||
* support skinning/theming | |||
This is supposed to support modeling complex avionics like a PFD, ND, EFB, CDU etc - and, eventually, also the Avidyne Entegra R9. It's currently just a prototype, but it gets away with very little code and we really only need a few more "skins" for common avionics. I am willing to extend this over time and help maintain it if people can agree to use something like this. It should be straightforward to allow such "MFDs" to be reloaded from disk at run-time, i.e. for more rapid prototyping. | |||
It's currently just a prototype, but it gets away with very little code and we really only need a few more "skins" for common avionics. | |||
I am willing to extend this over time and help maintain it if people can agree to use something like this. | |||
It should be straightforward to allow such "MFDs" to be reloaded from disk at run-time, i.e. for more rapid prototyping. | |||
{{Note|This is work in progress - the idea is to identify required building blocks to easily specify most MFD functionality in a generic fashion, without requiring a ton of custom Nasal code and without being specific to a single type of MFD. The whole concept is based on [[FlightGear_Missions_and_Adventures#XML_Extension_Framework]], i.e. providing a Nasal-space mechanism to expose and re-define building blocks to XML space. | {{Note|This is work in progress - the idea is to identify required building blocks to easily specify most MFD functionality in a generic fashion, without requiring a ton of custom Nasal code and without being specific to a single type of MFD. The whole concept is based on [[FlightGear_Missions_and_Adventures#XML_Extension_Framework]], i.e. providing a Nasal-space mechanism to expose and re-define building blocks to XML space. | ||
| Line 293: | Line 140: | ||
The Nasal/Canvas data structures will be transparently created and compiled for each MFD. Each MFD consists of an arbitrary number of buttons, modes and pages. Each MFD can be instantiated multiple times, and each MFD is designed to be aircraft/instrument agnostic, i.e. also works just in a conventional Canvas dialog. Buttons can trigger and switch between modes, and modes may have pages (conventionally implemented through a single SVG file). Each page consists of an arbitrary number of page elements, which can in turn be animated/updated via listeners and timers. Should look at existing displays, especially the [[NavDisplay]] and the update() method in navdisplay.mfd, but the most complete test-case would probably be the [[Avidyne Entegra R9]] }} | The Nasal/Canvas data structures will be transparently created and compiled for each MFD. Each MFD consists of an arbitrary number of buttons, modes and pages. Each MFD can be instantiated multiple times, and each MFD is designed to be aircraft/instrument agnostic, i.e. also works just in a conventional Canvas dialog. Buttons can trigger and switch between modes, and modes may have pages (conventionally implemented through a single SVG file). Each page consists of an arbitrary number of page elements, which can in turn be animated/updated via listeners and timers. Should look at existing displays, especially the [[NavDisplay]] and the update() method in navdisplay.mfd, but the most complete test-case would probably be the [[Avidyne Entegra R9]] }} | ||
<gallery mode=packed> | |||
Gpsmap196-canvas-panel-page.png|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]. | |||
Canvas-mfd-framework-prototyping.png|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]]. | |||
Canvas-mfd-framework-prototyping-with-mapstructure.png|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]]. | |||
Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown. | |||
</gallery> | |||
{{Newsletter-article-start|Canvas System|By [[User:Hooray|Hooray]]}} | |||
The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too. | |||
For more info, I suggest to check out: [[MapStructure#Porting the map dialog]] | |||
<gallery mode=packed> | |||
MapStructureDialog.png|You can basically create arbitrary layers, even for custom objects/positions | |||
Map-canvas-chain-home-editor.png|The same method can be used for creating a "live" radar display | |||
MapStructure-TFC-Troubleshooting.png| | |||
Map-canvas-dialog-storms-overlay.png|But maps and layers can be fairly sophisticated, too - all 100% scripted | |||
</gallery> | |||
As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article. | |||
[[File: | {{Newsletter-article-start|GUI Launcher|By [[User:Hooray|Hooray]]}} | ||
[[File:Aircraft-center-prototype.png|270px|thumb|Canvas dialog showing the prototype for an [[Aircraft Center]] for directly installing/managing aircraft from within FlightGear, an upcoming feature scheduled for FlightGear 3.2, currently being developed by TheTom and Zakalawe]] | |||
The "built-in" GUI/launcher is one of the longest-standing feature requests - but it's not just about the GUI (which is rather straightforward in comparison), but about the simulator never having been developed with this requirement, i.e. run-time reinitialization, in mind - thus, things like "fgrun" (and a plethora of other external launchers) were developed, which acted as a front-end on top of FG, so that FG itself wouldn't need to be changed - i.e. kind of a "remote control" using command line arguments. So it's there for a reason - fgrun uses the FLTK GUI library, which while relatively simple, is much more powerful than our legacy GUI engine, PUI. | |||
Still, people have been asking for this for years, and it's thanks to pretty much a single person, Zakalawe, that switching aircraft is going to become possible pretty soon - he handled all the ugly work of cleaning up the simulator internals to make this happen - it's not exactly glamorous work, you gotta touch a ton of places, and you inevitably introduce a ton of regressions along the way. | Still, people have been asking for this for years, and it's thanks to pretty much a single person, Zakalawe, that switching aircraft is going to become possible pretty soon - he handled all the ugly work of cleaning up the simulator internals to make this happen - it's not exactly glamorous work, you gotta touch a ton of places, and you inevitably introduce a ton of regressions along the way. | ||
And yes, even the legacy FG GUI is entirely based on XML and configurable through just editiing XML files - but the collection of "widgets" (GUI controls like buttons, checkboxes, labels etc) is extremely small and very inflexible. | |||
This is something that is currently being addressed by TheTom and Zakalawe, who've both been working on a new Canvas GUI, and a new Canvas GUI dialog called "Aircraft Center", which -while still experimental- is intended to eventually allow end-users to easily download/install aircraft right within the simulator, and also switch between aircraft at run-time without having to exit/restart the simulator. | |||
Thus, adopting Canvas is going to address a number of long-standing issues, but it's obviously a process that only just got started, and it will not happen overnight - 2-3 release cycles are not far-fetched, that's how long the whole migration could very well take, unless there are more people interested in helping. | |||
{{Newsletter-article-start|Damage and disintegration|By [[User:Algernon|Algernon]]|FlightGear addons and mods}} | {{Newsletter-article-start|Damage and disintegration|By [[User:Algernon|Algernon]]|FlightGear addons and mods}} | ||