Canvas EFB framework: Difference between revisions
Line 266: | Line 266: | ||
}} | }} | ||
== 777 EFB Roadmap == | |||
=== Page Handling === | |||
{{cquote | {{cquote | ||
|<nowiki>Page Handling Parser: what would be your advice? Could you give me some working examples - consistent with my actual EFB framework - to be tested inside my code?</nowiki><br/><nowiki> | |<nowiki>Page Handling Parser: what would be your advice? Could you give me some working examples - consistent with my actual EFB framework - to be tested inside my code?</nowiki><br/><nowiki> | ||
Line 294: | Line 295: | ||
}} | }} | ||
}} | }} | ||
{{cquote | |||
|<nowiki> I really suggest to take a quick look at F-JJTH GPSMap196 - it's still a stub, much less functional than your work, but at least the code is compact that way. Understanding classes/OOP would be helpful though, but that will greatly simplify all your other work either way. So it would be worthwhile to read up a bit on OO and maybe work through 2-3 tutorials, or even just play with classes in the Nasal console. Let me know if you have any questions - better use the wiki for OO question, so that we can directly update the corresponding articles.</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211557#p211557 | |||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Tue Jun 03</nowiki> | |||
}} | |||
}} | |||
=== Text Handling === | |||
{{cquote | {{cquote | ||
Line 307: | Line 319: | ||
{{cquote | {{cquote | ||
|<nowiki>Procedural Charts | |<nowiki>Regarding your current way of text handling, yes, there is a much better way using Canvas - you are still using the old method that people used to use when canvas was not around, it is now deprecated. Like you say, the whole XML/setprop mess can be avoided these days by using Canvas. TheTom's CDU framework is using the new method</nowiki> | ||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211557#p211557 | |||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Tue Jun 03</nowiki> | |||
}} | |||
}} | |||
=== Procedural Charts === | |||
{{cquote | |||
|<nowiki>I don't like the idea at the moment: I've seen some tests you proposed in the developmnet of the 'Airport Location' dialog: looking at Boeing manuals we want to stick to real charts, hi-res, full of details for the pilot; we just want to display a crisp nice .jpg, or .png, or svg, file on the screen (Boeing 777's EFB has a fixed ratio of 1.412371 proportion between width and height); a nice possibility, though, would be to superimpose some symbols over those charts, in time)</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211554#p211554 | |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211554#p211554 | ||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
|date=<nowiki>Tue Jun 03</nowiki> | |||
}} | |||
}} | |||
{{cquote | |||
|<nowiki>Procedural charts are not needed - PDFs converted to PNGs should work just fine. Displaying symbol overlays is straightforward to do using Canvas, and those could even be moving and animated symbols using the MapStructure framework</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211557#p211557 | |||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Tue Jun 03</nowiki> | |date=<nowiki>Tue Jun 03</nowiki> | ||
}} | }} |
Revision as of 01:06, 3 June 2014
This article is a stub. You can help the wiki by expanding it. |
Note:
While this article is based on considerable community feedback, there's nobody working on this currently.
Mentors: Hyde[3], Hooray (get in touch to learn more) |
Started in | 06/2014 |
---|---|
Description | EFB Framework |
Contributor(s) | I-NEMO, Hyde, Hooray |
Status | discussion (777-200ER/prototype) |
Subforum | http://forum.flightgear.org/viewforum.php?f=71 |
The FlightGear forum has a subforum related to: Canvas |
Background
I'm trying to change 777's indicators to canvas system now.
Could someone lecture me how to display Airport Chart - Aircraft/Instruments/Textures/od_groundradar.rgb - on EFB?
Or is there any other equivalent method?
— Hyde (Tue Oct 22). How to display Airport Chart?.
|
Feel free to work on the EFB (don't have that in the 744), but please don't waste any time on the rest of the displays. I already have PFD and ND for the 744 and am making them as generic as possible. They will end up in Instruments/ so we can re-use them on other aircraft.
— Gijs (Tue Oct 22). Re: How to display Airport Chart?.
|
I'm quite busy with modeling a new EFB and other stuff.
— I-NEMO (Wed Apr 30). Re: New Boeing 777 Seattle download site (git).
|
we are working on the new EFB, which is coming out nicely, we presume.
— I-NEMO (Tue May 13). Re: New Boeing 777 Seattle download site (git).
|
I'm currently developing a new EFB for the 777 Seattle; even if I'm inspiring to Omega95's job made for the 787 Dreamliner (which, BTW, I'm not able to load onto FG 3.0!...a mystery!), I'm working on it since more than a month (everyday, several hours), the task is a long one. I do hope to be able to have a "rude" version of the new EFB (with some simplifications and enhancements, looking to Boeing's 777 EFB Manuals) to submit to my partners in about ten days (I'm totally a newbie on nasal! [Ouch! ]...but I'm trying to learn).
Then, we will go through our internal testing and improvement.
Then, again, the new EFB will be released 'as-is', so the FG Pilots might play with it and report back to us what's wrong, and what might be improved.
— I-NEMO (Tue May 06). Re: New Boeing 777 Seattle download site (git).
|
we may not even need to run external EFB software, because our integrated scripting system in combination with the Canvas 2D rendering system may provide all the hooks required to render such geo-referenced imagery directly inside FlightGear with very little work needed - we even have http bindings to load images on the fly.
— Hooray (Sun Apr 20). Re: A project to create a source of free geo-referenced inst.
|
we should have most building blocks required for this in place, maybe some things are not yet exposed to scripting space currently (but still available in C++) - but being able to run this directly inside FG would be kinda useful obviously, especially because of recent work in this area, especially the tiled map support, HTTP bindings, SGPath exposure (disk access). And being able to directly geo-align raster images has been previously discussed, too
— Hooray (Mon Apr 21). Re: A project to create a source of free geo-referenced inst.
|
Right now the script basically just a creates .PNG and a .VRT for a given plate, suitable for loading directly into something like QGIS
If you run the script for the entire set of plates (eg. "multithread.sh .") using the -s option you'll get a statistics file which has all of the lon/lat extents for each plate in it (which is how I made the spreadsheet I linked here)
— jlmcgraw (Mon Apr 21). Re: A project to create a source of free geo-referenced inst.
|
extending our 2D rendering API (Canvas) to provide a mechanism to geo-align such images would be kinda useful for a variety of purposes, we already have a "map" element that can automatically geo-reference lat/lon pairs without any manual work involved - and we also have support for a raster image element.
— Hooray (Mon Apr 21). Re: A project to create a source of free geo-referenced inst.
|
all we have to do to display such charts within FlightGear is to load the chart image and apply the matrix created by the script. In the case of VRT files, it should be enough to just read the GeoTransform tag and set it as matrix on the Image element inside the canvas (with the parent element set up to have a coordinate system matching the current position and range).
Some central server for collecting such free and geo-referenced charts would surely be useful and probably does not require too much space and bandwith. These charts would not only be useful for FlightGear, but also for real aviation applications, like EFBs. I think I saw this or a similar script somewhere inside the sources of Avare?
— TheTom (Wed Apr 23). Re: A project to create a source of free geo-referenced inst.
|
having just a web service that maintains and provides those charts would be straightforward and should not require any work on the Canvas side of things, also it avoids redundant work, because charts would remain identical normally, i.e. would only need to be created once. Not sure what the geo-coding question was all about ..
— Hooray (Wed Apr 23). Re: A project to create a source of free geo-referenced inst.
|
The 777 EFB
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: 1) to do something to compensate for the lacking of an EFB inside the Seattle. 2) to actually try (I repeat it: 'try') to learn some first essentials of nasal. — I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
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. My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. — I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
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...
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
the EFB manual is made by Jeppesen for Boeing, and a particular ('vertical') approach must be considered by the casual developer (myself, in this case). Many functions devised by Jeppesen for Boeing are not easily simulated in FG; so - for the moment - I decided to skip them, and I concentrate on what I considered nice and/or useful (again, it's of course a matter of opinion). [Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective] — I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
the EFB manual is made by Jeppesen for Boeing, and a particular ('vertical') approach must be considered by the casual developer (myself, in this case). Many functions devised by Jeppesen for Boeing are not easily simulated in FG; so - for the moment - I decided to skip them, and I concentrate on what I considered nice and/or useful (again, it's of course a matter of opinion). [Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective] — I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
As I said above, my aim was to give the Seattle's Pilot the feeling of a 777's EFB. I doubt that an Airbus might have been developed using the same Boeing's EFB. The reason is easy: the two aircraft were 'thought' differently by the actual engineers, and both Boeing and Airbus would have - not only possibly used different graphics - but also different software behavior. Certainly, if Jeppesen was the EFB contractor both for Boeing and Airbus, Jeppesen's engineers undoubtedly used the 'standard' core of one of their EFB; but then, almost immediately they 'adapted' the EFB functionality so that Boeing and Airbus expectations could be respectively satisfied. At the end, we have two differently behaving tools (they do obviously interface to their respective FMC and instrumentation, which - again - works differently). Not to mention further applications added for newer versions, stemmed again in time by Boeing and Airbus. — I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
I found Omega95's EFB from the 787 Dreamliner; I've studied it, 'thinking' that it could be considered as a good starting point (I somehow considered that 'that' piece of nasal was already considered as Standard and/or portable by the FG's community. And - again in my opinion - I considered that some of the logic behind Omega95's nice piece of software should have been adapted to the current Seattle Status; and I've tried, with my bad knowledge of nasal, to make something...functional. (it was Hyde's brilliant suggestion to use hashes for the airport data; but, I want to take those lines out of efb.nas, so to have a sort of easily accessible sort of DB
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
Nevertheless, I do agree with you, Hooray; I will gladly follow any working suggestion, and appreciate any real help in fixing the EFB; but, please, do consider that: We want to have a Boeing 777 EFB (The device is already obsolete; real pilots now use other fancy devices on board).
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans ?.
|
I like the fact that the code is using hashes to configure some things at the top of the file, but otherwise, it's still fairly non-generic and not very flexible at the moment. And structurally it is certainly overlapping with existing code, such as the Avidyne Entegra, or even just the GPSMap196 - especially the page handling and mode switching stuff is not yet sufficiently generic. There's a reason that we've been discussing a generic Canvas-based EFB framework, which should ideally use a common "MFD" framework
— Hooray (Sun Jun 01). 777 EFB status & plans ?.
|
Functionality-wise there seem to be a lot of corner cases handled already by the efb.nas file: https://gitorious.org/fg/fgdata/source/Aircraft/777/Nasal/efb.nas
But especially event handling and mode switching is extremely explicit and non-generic at the moment, a problem that the original GPSMap196 code also had - the whole thing could probably be reduced by about 60% if we could work out a way to find common goals
And the whole point is flexibility and generic code, so that things like the ND, PFD or EFB use the same back-end for implementing MFDs, and the same back-end for event handling, including page- and mode management.
— Hooray (Sun Jun 01). 777 EFB status & plans ?.
|
The basic recipe to make this sufficiently generic is basically what we did with Gijs' original ND code:
— Hooray (Sun Jun 01). 777 EFB status & plans ?.
|
777 EFB Roadmap
Page Handling
Page Handling Parser: what would be your advice? Could you give me some working examples - consistent with my actual EFB framework - to be tested inside my code? I would test them, study them and come back with deeper questions and so forth. — I-NEMO (Tue Jun 03). Re: 777 EFB status & plans ?.
|
I'd like to get a crystal-clear example about integrating a Canvas screen for a given page (remember I'm an old-school man, I like to be detailed; even if a concept is new to me, I first want to proper understand the Philosophy behind a certain solution, then I would study the logic, and then the syntax): how to create the instance, how to define properties like size, content, interactions and so forth.
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans ?.
|
I presume I could elaborate and reproduce it all along my current code, and get back to you with problems and results, so to solve issues, refine the coding, and to get it work...
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans ?.
|
I really suggest to take a quick look at F-JJTH GPSMap196 - it's still a stub, much less functional than your work, but at least the code is compact that way. Understanding classes/OOP would be helpful though, but that will greatly simplify all your other work either way. So it would be worthwhile to read up a bit on OO and maybe work through 2-3 tutorials, or even just play with classes in the Nasal console. Let me know if you have any questions - better use the wiki for OO question, so that we can directly update the corresponding articles.
— Hooray (Tue Jun 03). Re: 777 EFB status & plans ?.
|
Text Handling
the Text object matrix is made by about 20 lines of text (to be consistent with some added applications, like the Descent Rate calculator, I had to add some more lines with different horizontal, vertical position on the screen, and different Font Size). The piece of .xml code (EFB_display_lines.xml) which handles a given line of text (taken from Omega95' software) is quite large; so, I splitted the .xml related to all the text lines from the main EFB xml. Still, I do not like it at all: is there a better solution for that?...the ideal would be to have just one piece of code to display a line, and a bunch of, say, 15 variables for all the various text properties (positions, alignment, font, font size, character size, and so forth); can nasal pass these variables to .xml withour addressing each time a setprop call? Or, even better: can we avoid .xml coding for the text matrix, and handle it from within nasal? — I-NEMO (Tue Jun 03). Re: 777 EFB status & plans ?.
|
Regarding your current way of text handling, yes, there is a much better way using Canvas - you are still using the old method that people used to use when canvas was not around, it is now deprecated. Like you say, the whole XML/setprop mess can be avoided these days by using Canvas. TheTom's CDU framework is using the new method
— Hooray (Tue Jun 03). Re: 777 EFB status & plans ?.
|
Procedural Charts
I don't like the idea at the moment: I've seen some tests you proposed in the developmnet of the 'Airport Location' dialog: looking at Boeing manuals we want to stick to real charts, hi-res, full of details for the pilot; we just want to display a crisp nice .jpg, or .png, or svg, file on the screen (Boeing 777's EFB has a fixed ratio of 1.412371 proportion between width and height); a nice possibility, though, would be to superimpose some symbols over those charts, in time)
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans ?.
|
Procedural charts are not needed - PDFs converted to PNGs should work just fine. Displaying symbol overlays is straightforward to do using Canvas, and those could even be moving and animated symbols using the MapStructure framework
— Hooray (Tue Jun 03). Re: 777 EFB status & plans ?.
|
Design
rgb files are conventional images, like jpg/png - so they are so called "raster images" (unlike SVGs, which are "vector images"). So to display raster images, you can use the tutorial at: http://wiki.flightgear.org/Howto:Using_raster_images_and_nested_canvases This assumes that you have previously created the corresponding charts as image files, a technique that omega95 and redneck have been using for a while.
For starters, you can use the Nasal console to play around with it: http://wiki.flightgear.org/Nasal_Console
Now, to add an EFB dialog to the 777, you could use the old dialogs and embed a canvas region, see the tutorial at: http://wiki.flightgear.org/Howto:Adding_a_canvas_to_a_GUI_dialog
If you want to display vector images (SVG) or custom-drawn maps, you'll want to use OpenVG paths
To display a procedurally-created airport chart (without adding a precreated raster image for each airport), you'll probably want to use the technique used by the airport selection dialog