6,566
edits
Canvas EFB framework: Difference between revisions
Jump to navigation
Jump to search
m
Switch to the {{forum url}} template for all forum links.
(Switch to the {{forum url}} and {{forum link}} templates for all forum links. The links within {{cite web}} have been excluded.) |
m (Switch to the {{forum url}} template for all forum links.) |
||
| Line 29: | Line 29: | ||
|Looking at the Boeing 777 EFB (which is driven by a Jeppesen Application based on Windows), they use PDF files (in hi-res) for Navigation Charts (and for Aerodromes too, I presume) in order to avoid any zooming problem.<br/> | |Looking at the Boeing 777 EFB (which is driven by a Jeppesen Application based on Windows), they use PDF files (in hi-res) for Navigation Charts (and for Aerodromes too, I presume) in order to avoid any zooming problem.<br/> | ||
I'd assume that a hi-res .pdf file would be the best easy solution, at the moment (it will take some time to define an acceptable ''standard'' for procedural charts, I presume): is Canvas capable of displaying a .pdf file? | I'd assume that a hi-res .pdf file would be the best easy solution, at the moment (it will take some time to define an acceptable ''standard'' for procedural charts, I presume): is Canvas capable of displaying a .pdf file? | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213157}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 45: | Line 45: | ||
<br/> | <br/> | ||
Also see this related discussion on the XP forum: [http://forums.x-plane.org/?showtopic{{=}}46676 http://forums.x-plane.org/?showtopic{{=}}46676] | Also see this related discussion on the XP forum: [http://forums.x-plane.org/?showtopic{{=}}46676 http://forums.x-plane.org/?showtopic{{=}}46676] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213159}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 52: | Line 52: | ||
}} | }} | ||
{{FGCquote|1= More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: {{forum link|p=258282}}|2= {{cite web | url = | {{FGCquote|1= More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: {{forum link|p=258282}}|2= {{cite web | url = {{forum url|p=258879}} | title = <nowiki>Canvas MFD framework vs. EFB functionality</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 27th, 2015 }}}} | ||
{{FGCquote|1= It might be also possible to decrease the quality of any PDFs a little to drop the sie. It would be good to have everything self contained, for easy reference. Was the procedure to carry these on the shuttle for quick lookups? Hmmm, I'm now wondering about a {{forum link|p=214381|text=canvas PDF viewer}}!|2= {{cite web | url = | {{FGCquote|1= It might be also possible to decrease the quality of any PDFs a little to drop the sie. It would be good to have everything self contained, for easy reference. Was the procedure to carry these on the shuttle for quick lookups? Hmmm, I'm now wondering about a {{forum link|p=214381|text=canvas PDF viewer}}!|2= {{cite web | url = {{forum url|p=257936}} | title = <nowiki>Re: Space Shuttle</nowiki> | author = <nowiki>bugman</nowiki> | date = Sep 18th, 2015 }}}} | ||
{{FGCquote|1= See: [[Canvas Development#PDF]]It may make sense to revisit this idea, supporting a subset of PDF would not be too difficult, but it would be better to really use a PDF library and OSG's built-in suport for rendering a PDF to a texture, which could the be easily turned into a new Canvas Element, as per the example at: [[Canvas Development#Adding a new Element]]The coding part is relatively straightforward (basically copy&paste), but getting the dependencies/cmake magic right for all supported FG platforms would probably require a bit of work.|2= {{cite web | url = | {{FGCquote|1= See: [[Canvas Development#PDF]]It may make sense to revisit this idea, supporting a subset of PDF would not be too difficult, but it would be better to really use a PDF library and OSG's built-in suport for rendering a PDF to a texture, which could the be easily turned into a new Canvas Element, as per the example at: [[Canvas Development#Adding a new Element]]The coding part is relatively straightforward (basically copy&paste), but getting the dependencies/cmake magic right for all supported FG platforms would probably require a bit of work.|2= {{cite web | url = {{forum url|p=258282}} | title = <nowiki>Re: 777 EFB: initial feedback</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 21st, 2015 }}}} | ||
{{FGCquote|1= I checked the OSG source tree and examples there, the C++ code is directly dealing with an osg::Image and the cpp file is just 100 lines, so it seems fairly compact: | {{FGCquote|1= I checked the OSG source tree and examples there, the C++ code is directly dealing with an osg::Image and the cpp file is just 100 lines, so it seems fairly compact: | ||
| Line 63: | Line 63: | ||
* https://searchcode.com/codesearch/view/20919788/ | * https://searchcode.com/codesearch/view/20919788/ | ||
Adapting our CanvasImage code to also support PDF files should be fairly straightforward and not even take very long - so we can revisit this post 3.2 and I can also post some patches to get this started.|2= {{cite web | url = | Adapting our CanvasImage code to also support PDF files should be fairly straightforward and not even take very long - so we can revisit this post 3.2 and I can also post some patches to get this started.|2= {{cite web | url = {{forum url|p=214381}} | title = <nowiki>Canvas Element for rendering PDFs ? (split)</nowiki> | author = <nowiki>Hooray</nowiki> | date = Jul 8th, 2014 }}}} | ||
== Motivation == | == Motivation == | ||
| Line 78: | Line 78: | ||
{{FGCquote|1= at least a big part of it is about having a central location where EFBs built into the aircrafts can find data that all of them need. That are not SIDs or STARs as XML files (or whatever format would be used by the route manager) , but the corresponding approach plates, airport charts etc., i.e. stuff that you want to present to the user as graphics. Of course, there could bne more to such a framework in supporting functionalities shared by all EFBs.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34494204/ | title = <nowiki>Re: [Flightgear-devel] Electronic Flight Bag</nowiki> | author = <nowiki>Jens Thoms Toerring</nowiki> | date = Sep 27th, 2015 }}}} | {{FGCquote|1= at least a big part of it is about having a central location where EFBs built into the aircrafts can find data that all of them need. That are not SIDs or STARs as XML files (or whatever format would be used by the route manager) , but the corresponding approach plates, airport charts etc., i.e. stuff that you want to present to the user as graphics. Of course, there could bne more to such a framework in supporting functionalities shared by all EFBs.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34494204/ | title = <nowiki>Re: [Flightgear-devel] Electronic Flight Bag</nowiki> | author = <nowiki>Jens Thoms Toerring</nowiki> | date = Sep 27th, 2015 }}}} | ||
{{FGCquote|1= the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.But we do have code/prototypes doing EFB handling using Nasal & Canvas|2= {{cite web | url = | {{FGCquote|1= the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.But we do have code/prototypes doing EFB handling using Nasal & Canvas|2= {{cite web | url = {{forum url|p=258879}} | title = <nowiki>Canvas MFD framework vs. EFB functionality</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 27th, 2015 }}}} | ||
| Line 88: | Line 88: | ||
Could someone lecture me how to display Airport Chart - Aircraft/Instruments/Textures/od_groundradar.rgb - on EFB? | Could someone lecture me how to display Airport Chart - Aircraft/Instruments/Textures/od_groundradar.rgb - on EFB? | ||
Or is there any other equivalent method?</nowiki> | Or is there any other equivalent method?</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=192247}} | ||
|title=<nowiki>How to display Airport Chart?</nowiki> | |title=<nowiki>How to display Airport Chart?</nowiki> | ||
|author=<nowiki>Hyde</nowiki> | |author=<nowiki>Hyde</nowiki> | ||
| Line 97: | Line 97: | ||
{{cquote | {{cquote | ||
|<nowiki>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.</nowiki> | |<nowiki>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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=192251}} | ||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |title=<nowiki>Re: How to display Airport Chart?</nowiki> | ||
|author=<nowiki>Gijs</nowiki> | |author=<nowiki>Gijs</nowiki> | ||
| Line 106: | Line 106: | ||
{{cquote | {{cquote | ||
|<nowiki>I'm quite busy with modeling a new EFB and other stuff.</nowiki> | |<nowiki>I'm quite busy with modeling a new EFB and other stuff.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=207673}} | ||
|title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | |title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 115: | Line 115: | ||
{{cquote | {{cquote | ||
|<nowiki>we are working on the new EFB, which is coming out nicely, we presume.</nowiki> | |<nowiki>we are working on the new EFB, which is coming out nicely, we presume.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=209355}} | ||
|title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | |title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 126: | Line 126: | ||
Then, we will go through our internal testing and improvement. | 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.</nowiki> | 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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=208440}} | ||
|title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | |title=<nowiki>Re: New Boeing 777 Seattle download site (git)</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 135: | Line 135: | ||
{{cquote | {{cquote | ||
|<nowiki>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.</nowiki> | |<nowiki>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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206535}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 144: | Line 144: | ||
{{cquote | {{cquote | ||
|<nowiki> 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</nowiki> | |<nowiki> 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</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206581}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 156: | Line 156: | ||
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) | 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) | ||
</nowiki> | </nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206589}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>jlmcgraw</nowiki> | |author=<nowiki>jlmcgraw</nowiki> | ||
| Line 165: | Line 165: | ||
{{cquote | {{cquote | ||
|<nowiki>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.</nowiki> | |<nowiki>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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206592}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 176: | Line 176: | ||
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?</nowiki> | 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?</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206788}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>TheTom</nowiki> | |author=<nowiki>TheTom</nowiki> | ||
| Line 185: | Line 185: | ||
{{cquote | {{cquote | ||
|<nowiki> 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 ..</nowiki> | |<nowiki> 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 ..</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=206792}} | ||
|title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | |title=<nowiki>Re: A project to create a source of free geo-referenced inst</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 205: | Line 205: | ||
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki><br/><nowiki> | 2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki><br/><nowiki> | ||
</nowiki> | </nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 217: | Line 217: | ||
</nowiki><br/><nowiki> | </nowiki><br/><nowiki> | ||
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki> | My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 226: | Line 226: | ||
{{cquote | {{cquote | ||
|<nowiki>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...</nowiki> | |<nowiki>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...</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 236: | Line 236: | ||
|<nowiki>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).</nowiki><br/><nowiki> | |<nowiki>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).</nowiki><br/><nowiki> | ||
[Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective]</nowiki> | [Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective]</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 247: | Line 247: | ||
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.</nowiki><br/><nowiki> | 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.</nowiki><br/><nowiki> | ||
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.</nowiki> | 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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 256: | Line 256: | ||
{{cquote | {{cquote | ||
|<nowiki> 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</nowiki> | |<nowiki> 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</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 272: | Line 272: | ||
</nowiki><br/><nowiki> | </nowiki><br/><nowiki> | ||
My aim is to make a decent piece of software, which of course might be reused by someone else in the future; but my primary aim is the Boeing 777 Seattle, portable or not portable.</nowiki> | My aim is to make a decent piece of software, which of course might be reused by someone else in the future; but my primary aim is the Boeing 777 Seattle, portable or not portable.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211550}} | ||
|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> | ||
| Line 281: | Line 281: | ||
{{cquote | {{cquote | ||
|<nowiki>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</nowiki> | |<nowiki>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</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211410}} | ||
|title=<nowiki>777 EFB status & plans ?</nowiki> | |title=<nowiki>777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 293: | Line 293: | ||
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.</nowiki> | 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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211410}} | ||
|title=<nowiki>777 EFB status & plans ?</nowiki> | |title=<nowiki>777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 307: | Line 307: | ||
* extracting useful code and generalizing it | * extracting useful code and generalizing it | ||
* integrating the whole thing with existing instruments (ND, PFD, EICAS) | * integrating the whole thing with existing instruments (ND, PFD, EICAS) | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211410}} | ||
|title=<nowiki>777 EFB status & plans ?</nowiki> | |title=<nowiki>777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 317: | Line 317: | ||
{{cquote | {{cquote | ||
|<nowiki>I don't think you need to start from scratch at all, I would instead incrementally "modernize" some portions of your code, and prioritize updating those portions that you consider too inflexible/fragile at the moment, such as page handling for example.</nowiki> | |<nowiki>I don't think you need to start from scratch at all, I would instead incrementally "modernize" some portions of your code, and prioritize updating those portions that you consider too inflexible/fragile at the moment, such as page handling for example.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211557}} | ||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 327: | Line 327: | ||
|Current development ('modernisation' phase) of the '''Boeing 777 Seattle's EFB''' is going on nicely; the code is shorter, more readable and cleaner.<br/> | |Current development ('modernisation' phase) of the '''Boeing 777 Seattle's EFB''' is going on nicely; the code is shorter, more readable and cleaner.<br/> | ||
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). | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213104}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 338: | Line 338: | ||
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. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213104}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 347: | Line 347: | ||
{{FGCquote | {{FGCquote | ||
|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... | |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... | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213104}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 357: | Line 357: | ||
|<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> | ||
I would test them, study them and come back with deeper questions and so forth.</nowiki> | I would test them, study them and come back with deeper questions and so forth.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211554}} | ||
|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> | ||
| Line 366: | Line 366: | ||
{{cquote | {{cquote | ||
|<nowiki>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.</nowiki> | |<nowiki>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.</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211554}} | ||
|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> | ||
| Line 375: | Line 375: | ||
{{cquote | {{cquote | ||
|<nowiki>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...</nowiki> | |<nowiki>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...</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211554}} | ||
|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> | ||
| Line 384: | Line 384: | ||
{{cquote | {{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> | |<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= | |{{cite web |url={{forum url|p=211557}} | ||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 393: | Line 393: | ||
{{FGCquote | {{FGCquote | ||
|Random thought: you know the view.nas code, the view managers? They have init, start, update, stop methods, which I think could be really helpful for pages as well. (Plus a register method to add a view-handler-aka-page | |Random thought: you know the view.nas code, the view managers? They have init, start, update, stop methods, which I think could be really helpful for pages as well. (Plus a register method to add a view-handler-aka-page | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213089}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Philosopher</nowiki> | |author=<nowiki>Philosopher</nowiki> | ||
| Line 408: | Line 408: | ||
<br/> | <br/> | ||
Technically, I was really just using those experiments to come up with something more flexible in XML space (where we could trivially support such code blocks/tags), which I am hoping to extend over time, assuming that people would be willing to adopt such a system: {{forum link|p=212029|title=Framework-centric aircraft-agnostic avionics development}} | Technically, I was really just using those experiments to come up with something more flexible in XML space (where we could trivially support such code blocks/tags), which I am hoping to extend over time, assuming that people would be willing to adopt such a system: {{forum link|p=212029|title=Framework-centric aircraft-agnostic avionics development}} | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213090}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 421: | Line 421: | ||
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.</nowiki><br/><nowiki> | 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.</nowiki><br/><nowiki> | ||
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?</nowiki> | 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?</nowiki> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211554}} | ||
|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> | ||
| Line 430: | Line 430: | ||
{{cquote | {{cquote | ||
|<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> | |<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= | |{{cite web |url={{forum url|p=211557}} | ||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 456: | Line 456: | ||
# The visual outcome of a procedurally created chart can be 100% customized, it's just a Nasal file that draws all those lines - colors, line width, labels etc (you name it) can be completely customized. You'd probably want to look at $FG_ROOT/Nasal/canvas/map/*.draw files for the handling of PARKING.draw, RUNWAYS.draw and TAXIWAYS.draw - those are standard Nasal functions that render to a group. However, this should really just serve as an example for the time being, because those files are going to be updated and ported to MapStructure during the upcoming release cycle (post 3.2), and people wanting to draw such diagrams should really be using Philosopher's MapStructure framework. | # The visual outcome of a procedurally created chart can be 100% customized, it's just a Nasal file that draws all those lines - colors, line width, labels etc (you name it) can be completely customized. You'd probably want to look at $FG_ROOT/Nasal/canvas/map/*.draw files for the handling of PARKING.draw, RUNWAYS.draw and TAXIWAYS.draw - those are standard Nasal functions that render to a group. However, this should really just serve as an example for the time being, because those files are going to be updated and ported to MapStructure during the upcoming release cycle (post 3.2), and people wanting to draw such diagrams should really be using Philosopher's MapStructure framework. | ||
# Regarding airnav.com: there's no account needed, those charts can be directly accessed and downloaded, they're using standard ICAO codes to look up the corresponding PDF files. | # Regarding airnav.com: there's no account needed, those charts can be directly accessed and downloaded, they're using standard ICAO codes to look up the corresponding PDF files. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213105}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 466: | Line 466: | ||
{{cquote | {{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> | |<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= | |{{cite web |url={{forum url|p=211554}} | ||
|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> | ||
| Line 475: | Line 475: | ||
{{cquote | {{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> | |<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= | |{{cite web |url={{forum url|p=211557}} | ||
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | |title=<nowiki>Re: 777 EFB status & plans ?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 493: | Line 493: | ||
<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. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213084}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 506: | Line 506: | ||
The fact that FG may not get into the AIRAC update's cycles, is not that important at the moment...the main issue here is that FG data should be consistent with the real world data; if it reflects 2007 data or 2014 it's not really important, I think. The point is that if we want to simulate the real world, we have to take into account real world data.<br/> | The fact that FG may not get into the AIRAC update's cycles, is not that important at the moment...the main issue here is that FG data should be consistent with the real world data; if it reflects 2007 data or 2014 it's not really important, I think. The point is that if we want to simulate the real world, we have to take into account real world data.<br/> | ||
Again: it's just a matter of setting up a sort of standard. But it should be based on reality, not on our simulation. Otherwise, we'll all fly inside a nice '''indian reserve'''. | Again: it's just a matter of setting up a sort of standard. But it should be based on reality, not on our simulation. Otherwise, we'll all fly inside a nice '''indian reserve'''. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213115}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 526: | Line 526: | ||
I would go for real charts (available on the Web), rather than producing again thousands of 'partial' charts.<br/> | I would go for real charts (available on the Web), rather than producing again thousands of 'partial' charts.<br/> | ||
I wish that someone else interested in this issue might share his opinion on this. | I wish that someone else interested in this issue might share his opinion on this. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213115}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>I-NEMO</nowiki> | |author=<nowiki>I-NEMO</nowiki> | ||
| Line 537: | Line 537: | ||
[[Airport_Diagram_Generator]]<br/> | [[Airport_Diagram_Generator]]<br/> | ||
[[File:Adg-KSFO-0.png|250px]] [[File:Adg-KSFO-1.png|250px]] | [[File:Adg-KSFO-0.png|250px]] [[File:Adg-KSFO-1.png|250px]] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213110}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||