Board index FlightGear Development Canvas

777 EFB: initial feedback

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: 777 EFB: initial feedback

Postby Philosopher » Wed Jun 04, 2014 1:53 am

Hooray wrote in Tue Jun 03, 2014 10:22 pm:You can also directly use a foreach loop:
Code: Select all
var ChartSelection_Size = 30;
var ChartSelection = [];
setsize(ChartSelection, ChartSelection_Size);

foreach(var char; ChartSelection)
 char = "NULL";

Just for the record, this doesn't work: "var char" (as in "char = ") is treated like any other local variable, and changing it won't change the vector at all.

BTW: both forindex and foreach need a vector, not a number. The forindex basically tells it to run through each number that is less than the size – while it is still using the vector, it actually only looks at the size of the vector. quippe illam maditudinem vectoris modo spectat... SCNR :D
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: 777 EFB: initial feedback

Postby Hooray » Wed Jun 04, 2014 11:22 am

sorry, I kind of expected that this wouldn't work when I posted it, but then I recalled that I once read somewhere that foreach temporaries would be valid lvalues, so I went out on a limb here (without actually testing anything) ... probably shouldn't have guessed in the scope of this thread, and surely shouldn't have added this to the wiki. Thanks for clarifying though.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby I-NEMO » Tue Jun 17, 2014 5:02 pm

Hallo Hooray,

I've already applied some mods to the EFB.nas file, so that currently I have a size of about 2100 lines; I presume that going further on with 'modernization', the code will be properly shortned.

At the moment, I'm studying how to start the Canvas system, so to test a couple of things (page handling and text-matrix].

I've read this: http://wiki.flightgear.org/Howto:Add_a_2D_canvas_instrument_to_your_aircraft
and this: http://wiki.flightgear.org/Canvas_MCDU_Framework
The two examples are slightly different in coding, but they basically do the same thing;

I thought that TheTom's example was valuable just because the EFB uses a text-matrix, and some pages, callable by actions associated to a certain button click (EFB buttons are in my case 3d-objects from EFB.ac file); also, I liked the idea of a single Hash, doing all the major job...being the EFB an istrument that displays various pages and stuff, I wish to have a dynamic and editable structure, dealing with a single hash (containing everything, and easily editable and easy to develop for further pages and/or functions), instead of many lines of code for the various pages ...
So, I have created an EFB_MENU hash, containing, labels, pages, and actions, which is ok (just inserted one page into the hash, at the moment, because I need a starting test before proceeding).
Then, at the beginning of my current EFB.nas I've inserted (immediately after the usual variable declarations, and after the EFB_MENU hash declaration as well) , this piece of code which at the moment just handles the text-matrix, based on TheTom's MCDU example:

Code: Select all
#__________________________________________
#  Initialize CANVAS |
#__________________________________________|

var EFB_canvas = {
   canvas_settings: {
      "name": "EFB",        # The name is optional but allow for easier identification
      "size": [1024, 2048],    # Size of the underlying texture (should be a power of 2, required) [Resolution]
      "view": [1024, 2048],     # Virtual resolution (Defines the coordinate system of the canvas [Dimensions]
                        # which will be stretched the size of the texture, required)
      "mipmapping": 1,          # Enable mipmapping (optional)
   },
   new: func(placement)
   {
      var item = {
         parents: [EFB_canvas],
         canvas: canvas.new(EFB_canvas.canvas_settings),
         text_style: {
            'font': "Helvetica.txf",
            'character-size': 32,
            'character-aspect-ratio': 1.044
         }
      };


      item.canvas.addPlacement(placement);
      item.canvas.setColorBackground(0, 0, 0);
      # Create the EFB Canvas Group
      item.root = item.canvas.createGroup();

      # Create the EFB Canvas 'text' Child
      # Title Row
      item.title = item.root.createChild("text");
      item.title._node.setValues(item.text_style);
      item.title.setColor(1, 1, 1);
      item.title.setAlignment("center-center");
      # Left & Right rows
      item.l = { xpos = 0.005, align : "left-center", rows : setzize([], 20)};
      item.r = { xpos = -0.005, align : "right-center", rows : setzize([], 20)};

   for(var i = 0; i <20; i +=1) {
      var ypos = 16 + (2*i + 1) * 32;
      item.l.rows[i] = { ypos, ypos, texts: []}:
      item.r.rows[i] = { ypos, ypos + 32, texts: []}:
   }

      return item;
   }
   };


First question: I get a "bad hash/object initializer" error at line 215 (it's the var 'item' declaration inside function (placement), part of the EFB_Canvas hash: text_style : {'font'...'character-size'...'character-aspect-ratio', })
Could you advise?

Second question: in order to get a certain texture to be used by the Canvas system, I assume I should use this:

Code: Select all
EFB_canvas.addPlacement({"node": "a-textured-object-from-the-ac-file"});

So I presume I should add to EFB_Canvas hash an element for the relevant texture's name (.png, or .svg).
So, by looking at TheTom's example,... once I parse the 3d-buttons for a certain page selection (checking properties and stuff), is it sufficient to "set" the 'page' already stored in the 'EFB_MENU' hash page Element to get it displayed?

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby I-NEMO » Tue Jun 17, 2014 10:21 pm

Hooray,

forgot my First question; I've figured out a couple of Syntax errors, and fixed them. Now the Canvas Initialize section's code looks like this:

Code: Select all
#__________________________________________
#  Initialize CANVAS |
#__________________________________________|

var EFB_canvas = {
   canvas_settings: {
      "name": "EFB",        # The name is optional but allow for easier identification
      "size": [1024, 2048],    # Size of the underlying texture (should be a power of 2, required) [Resolution]
      "view": [1024, 2048],     # Virtual resolution (Defines the coordinate system of the canvas [Dimensions]
                        # which will be stretched the size of the texture, required)
      "mipmapping": 1,          # Enable mipmapping (optional)
   },
   new: func(placement)
   {
      var item = {
         parents: [EFB_canvas],
         canvas: canvas.new(EFB_canvas.canvas_settings),
         text_style: {
            'font': "Helvetica.txf",
            'character-size': 32,
            'character-aspect-ratio': 1.044
         }
      };


      item.canvas.addPlacement(placement);
      item.canvas.setColorBackground(0, 0, 0);
      # Create the EFB Canvas Group
      item.root = item.canvas.createGroup();

      # Create the EFB Canvas 'text' Child
      # Title Row
      item.title = item.root.createChild("text");
      item.title._node.setValues(item.text_style);
      item.title.setColor(1, 1, 1);
      item.title.setAlignment("center-center");
      # Left & Right rows
      item.l = { xpos : 0.005, align : "left-center", rows : setzize([], 20)};
      item.r = { xpos : -0.005, align : "right-center", rows : setzize([], 20)};

   for(var i = 0; i <20; i +=1) {
      var ypos = 16 + (2*i + 1) * 32;
      item.l.rows[i] = { ypos: ypos, texts: []};
      item.r.rows[i] = { ypos: ypos + 32, texts: []};
   }

      return item;
   }
   };

Sorry about that...

I would anyway appreciate an answer to my Second question.

Thanks,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Fri Jun 20, 2014 5:19 pm

This sounds all very promising, you seem to have made a lot of progress. But like I mentioned previously, I'd suggest not to adopt Canvas until the major structural issues are sorted - otherwise, you'll end up with "working" code that uses Canvas but looks like the old code and suffers from very similar issues. While ~2100 lines is obviously much better than the previous state, it's still fairly massive, and I don't believe that this should be 1:1 translated to Canvas as is. Like I said in the other thread, I'd suggest to split up the file and use io.include() to factor out different buidling blocks. And then it's page handling that needs to be generalized, probably according to the comments in the other two 777 EFB threads.


Hooray wrote:you are right that you should use Canvas - but I would suggest to proceed more slowly.

There's a reason that I suggested certain articles/tutorials to be worked through and understood first: Canvas code requires some more understanding about concepts like vectors, hashes and OOP. Which is why I suggested to proceed in a certain way, so that you can make tiny changes, optimize the code to become more compact, while also preparing your understanding for using more advanced Nasal concepts.

Basically, none of this is rocket science - with your background in physics you are even over-qualified, but Thorsten is also a physicist by profession, and he keeps mentioning how he had to understand some concepts to write more compact, and more readable/better maintainable code.

I don't think you will have any problems if you work through things the way I suggested. Indeed, just the mere fact that you are already considering to use Canvas, demonstrates to me clearly that you are understanding the limitations of the current code.

Then again, look at some of my own code: it's often also very ugly, and it is normal for such things to require a few "iterations", i.e. different versions of code parts that are improved and adapted over time, we commonly call this "refactoring": Optimizing the structure of the code, without changing any functionality, i.e. without introducing regressions.

For example, you mentioned the MFD article I sent to you: That is also basically the 2nd-3rd iteration of the work I've done for F-JJTH on his GPSMap196.
And over time it will probably evolve some more.

Like you said, Tom's code looks "Aramaic" to you - simply because you are trying to "develop a car, without having invented the wheel first" ;-)
That is why Tom's code looks so difficult - which is why I suggest to proceed according to my suggestions in the Canvas forum.
We need to walk before we can "run" :-)

So I would suggest to take it more slowly - it really is like learning a new language: writing a simple "paper" can be done with little knowledge, but writing a complex paper requires deeper understanding of the language and some of its patterns, like vectors, hashes and OOP.

Obviously you can also discuss such things on the main forum, in public.
But my suggestion would be to take it slowly: Starting with Canvas right now would be like trying to get your physics PhD even though you have really just mastered Newton's law ...

These things will fall into place automatically, but you need to give it some time - and experiment a little, and make sure that it's "fun" - otherwise the whole thing can be very frustrating, because there are so many novel/aramaic concepts ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby Hooray » Sat Jun 21, 2014 3:31 pm

Also, to clarify, and maybe add to this: 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).

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: http://wiki.flightgear.org/Canvas_MapSt ... xml_dialog

Image

As you can probably tell, these kinds of layers would be very useful for any kind of EFB related application.

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 without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby Philosopher » Sat Jun 21, 2014 5:04 pm

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 ;).)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: 777 EFB: initial feedback

Postby Hooray » Sat Jun 21, 2014 5:12 pm

Philosopher wrote in Sat Jun 21, 2014 5:04 pm: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 ;).)


right, pretty much the "proper" way to do this can be seen in the Avidyne Entegra R9 code - but even a simple workaround like the one used in the updated GPSMap196 code should do for starters, and would at least be more flexible than the current method, while also being straightforward to update/extend or revamp at some point.

Regarding init/start/update/stop methods, those would be straightforward to have/add, currently the code is just structured such that this is all handled by the page manager. I kind of introduced that assumption a while ago to get rid of all the explicit polling and settimer/maketimer weirdness, because there was some discussion about having one timer/callback per "page", which was a bit concerning :D

https://gitorious.org/fg/canvas-hackers ... 96/mfd.nas

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: Subject: Framework-centric aircraft-agnostic avionics development
Hooray wrote: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.

The whole thing works with building blocks like a screen, buttons, modes, pages, and page elements. It is intended to:
  • support multiple independent instances
  • be totally aircraft agnostic
  • support a pure dialog-driven mode
  • support skinning/theming

It 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.

The following screen shots will probably seem very familiar, but the GPSMap196 instrument shown here was constructed without using any Nasal code, it's just declarative PropertyList XML:

http://wiki.flightgear.org/Canvas_Glass_Cockpit_Efforts
Image
Image
Image
Image

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.
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby I-NEMO » Sat Jun 21, 2014 9:57 pm

Hallo Hooray,

thanks for your most precious&stimulating notes!...I'm learning a lot from them.

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).
These are the basic steps I have set up at the moment:

Some code-sections have been splitted up in separate files, and included in the main efb.nas module:
Code: Select all
# Here we include the EFB Pages' DataBase
io.include("EFB_Pages.db");
# Here we include the EFB Applications' DataBase
io.include("EFB_Applications.db");   
# Here we include the EFB Chart's DataBase
io.include("EFB_Charts.db");
# Here we include the EFB Conversion Factor's DataBase
io.include("EFB_CNV_Factors.db");
#

Canvas is now active and ok (contained in the main efb.nas file)
Code: Select all
#__________________________________________
#  Initialize CANVAS |
#__________________________________________|

var EFB_canvas = canvas.new({
      "name": "EFB",        
      "size": [1024, 1024],    
      "view": [511, 695],                          
      "mipmapping": 1,          
   });

EFB_canvas.addPlacement({"node": "Display"});

# Creates the Text-Matrix Canvas Group element and set some values
var EFB_group = EFB_canvas.createGroup();
# Creates the Text-Matrix Canvas Elements
# Creates Text Rows
var Text_Line_Size = 16;                         # Number of EFB's rows
setsize(Text_Line_L, Text_Line_Size);
setsize(Text_Line_R, Text_Line_Size);
var xpos_L = 22.0;
var xpos_R = 487.0;
var ypos = 87.5;
for(var i = 0; i < (Text_Line_Size - 1); i += 1)
{
   Text_Line_ID = "L_" ~ i;
   Text_Line_L[i] = EFB_group.createChild("text", Text_Line_ID)
               .setTranslation(xpos_L,ypos)        # x-left-position, y-position
               .setAlignment("left-center")    
               .setFont("Helvetica.txf")       
               .setFontSize(32,1)              
               .setColor(1,1,1)               
               .set("z-index",10)
               .setText("TEST");
   Text_Line_ID = "R_" ~ i;
   Text_Line_R[i] = EFB_group.createChild("text", Text_Line_ID)
               .setTranslation(xpos_R,ypos)        # x-right-position, y-position
               .setAlignment("right-center")    
               .setFont("Helvetica.txf")       
               .setFontSize(32,1)              
               .setColor(1,1,1)               
               .set("z-index",10)
               .setText("TEST");               
   Text_Line_L[i].hide();
   Text_Line_R[i].hide();
   ypos = ypos + 40.5;
}
# Creates Title
var Title = EFB_group.createChild("text", "Title")
               .setTranslation(255.5,27.1)        # x-left-position, y-position
               .setAlignment("center-center")    
               .setFont("Helvetica.txf")       
               .setFontSize(32,1)              
               .setColor(1,1,1)               
               .set("z-index",10)
               .setText("TITLE TEST");
Title.hide();
# Creates Helper
var Helper = EFB_group.createChild("text", "Helper")
               .setTranslation(255.5,654.5)        # x-left-position, y-position
               .setAlignment("center-center")    
               .setFont("Helvetica.txf")       
               .setFontSize(32,1)              
               .setColor(0,1,0)               
               .set("z-index",10)
               .setText("HELPER TEST");
Helper.hide();
# Creates Screen               
var screen = EFB_group.createChild("image")
            .setFile("Models/Instruments/EFB/Displays/Initialize_0.jpg")
            .setSize(511,695)
            .setTranslation(0,0);

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.
The Display element is then textured with all the various pages' textures, called by the page-handler (see here below).
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.

Pages (currently, 28 pages...and growing) are now handled by an Hash (contained in a separate file, EFB_pages.db); hash pages contains all the various pages' hashes, with a structure like this (MAIN MENU):
Code: Select all
var pages_path = "Models/Instruments/EFB/Displays/";

var pages = {

'MAIN_MENU' :
      {
         'title' : "MAIN MENU",
         'MENU': {subpage_label : "MAIN_MENU", action : (pages_path ~ "Main_Menu.jpg"), launch : "NULL"},
         'l1': {subpage_label : "AIRPORT MAP", action : (pages_path ~ "Loading.jpg"), launch : "NULL"},
         'l2': {subpage_label : "PERFORMANCE", action : (pages_path ~ "Performance_1.jpg"), launch : "NULL"},
         'l3': {subpage_label : "NULL", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},         
         'l4': {subpage_label : "APT INFO", action : (pages_path ~ "Airport_Info.jpg"), launch : "Display_APTINFO"},         
         'l5': {subpage_label : "NULL", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},
         'l6': {subpage_label : "NULL", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},         
         'l7': {subpage_label : "IDENT", action : (pages_path ~ "Ident_1.jpg"), launch : "Display_IDENT"},
         'l8': {subpage_label : "SYSTEM", action : (pages_path ~ "System_1.jpg"), launch : "NULL"},         
         'r1': {subpage_label : "VIDEO", action : (pages_path ~ "Video_1.jpg"), launch : "NULL"},
         'r2': {subpage_label : "DOCUMENTS", action : (pages_path ~ "Documents_1.jpg"), launch : "NULL"},
         'r3': {subpage_label : "TERMINAL CHARTS", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},
         'r4': {subpage_label : "NULL", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},
         'r5': {subpage_label : "UTILITIES", action : (pages_path ~ "PU_1.jpg"), launch : "NULL"},
         'r6': {subpage_label : "NULL", action : (pages_path ~ "NULL_1.jpg"), launch : "NULL"},
         'r7': {subpage_label : "MONITOR", action : (pages_path ~ "Monitor.jpg"), launch : "Display_FLIGHTMONITOR"},
         'r8': {subpage_label : "INITIALIZE", action : (pages_path ~ "Initialize_1.jpg"), launch : "NULL"},         
      },

subpage_label: it's the page to be set through (3D) button selection;
action: it's the page path/name to be loaded (texture on a Canvas object);
launch: it's the function containing all the necessary code for that subpage.

The page-handler ( a simple function Page_Set, which access the hashes and adresses Canvas accordingly) is contained in the main efb.nas file, and it's very short (1 line of code):
Code: Select all
...
   Page_Set : func (keypress, PAGE) {
   
      page.Reset_Text_Matrix();
      GOTO = pages[PAGE][keypress].action;
      SUB_PAGE = pages[PAGE][keypress].subpage_label;
      setprop("/instrumentation/efb/page", SUB_PAGE);
      screen.setFile(GOTO).show();
      if (pages[PAGE][keypress].launch != "NULL") {
         Page_Functions[pages[PAGE][keypress].launch]();
      };      
      PAGE = SUB_PAGE;
      if (PAGE == "NULL") {setprop("sim/sound/click10", 1)} else {setprop("sim/sound/click10", 0)};          # Plays a Warning sound
      keypress ="";
      return PAGE;
   },
...
...
...
if ((keypress != "") and (keypress != "l1"))
   {    
      efb.Page_Set(keypress, PAGE);
      PAGE = getprop("/instrumentation/efb/page");
   }


if (keypress == "l1") { setprop("/instrumentation/efb/page", "CHARTS");
setprop("/instrumentation/efb/chart/chartmenu", 0);
setprop("/instrumentation/efb/chart/zoom-in", 0);
ZoomFact = 0;
PanHFact = 0;
PanVFact = 0;
keypress = "";
}

As you see, I have already inserted a quick-and-short Reset_Text_Matrix() function, using a for loop to actually clear text-lines, and resetting them to their original values (see Canvas above). (at the end...no more silly repetitive lines for clearing&resetting text! :D )
The (keypress == 1) event it's still there, because I will deal with Charts section&functions once I'll finish setting up all the EFB pages and functions; so, it will be handled as a function and those lines will be eliminated.

The EFB Applications are treated as functions (called by the launch element in the pages hash), contained in a separate file (EFB_Applications.db); here's an example:
Code: Select all
...
var Page_Functions = {};      # this Hash will contain all the Pages' functions, called by the 'launch' element in the Hash 'pages'.
...
...
#__________________________________________________________________________________________
# Boeing 777 EFB Applications -> UTILITIES/GPS POSITION -----------------------------------|
#__________________________________________________________________________________________|

Page_Functions.Display_GPS = func {

   ypos = 450.0;
   Title.setText("GPS POSITION / SETTINGS").show();
   Text_Line_L[1].setTranslation(40.0,90.0).setAlignment("left-center").setFontSize(25,1).setColor(0,1,0).setText("Latitude: " ~ sprintf("%3.2f", getprop("/instrumentation/gps/indicated-latitude-deg")) ~ " degs").show();
   Text_Line_L[2].setTranslation(472.0,90.0).setAlignment("right-center").setFontSize(25,1).setColor(0,1,0).setText("Longitude: " ~ sprintf("%3.2f", getprop("/instrumentation/gps/indicated-longitude-deg")) ~ " degs").show();
   Text_Line_L[3].setTranslation(40.0,ypos).setAlignment("left-center").setFontSize(22,1).setColor(1,1,1).setText("GPS Mode: " ~ getprop("/instrumentation/gps/mode")).show();   
   Text_Line_L[4].setTranslation(300.0,ypos).setAlignment("left-center").setFontSize(22,1).setColor(1,1,1).setText("WayPoint ID: " ~ getprop("/instrumentation/gps/wp/wp[1]/ID")).show();   
   Text_Line_L[5].setTranslation(40.0,ypos+80.0).setAlignment("left-center").setFontSize(22,1).setColor(1,1,1).setText("Leg Distance: " ~ sprintf("%3.2f", getprop("/instrumentation/gps/wp/leg-distance-nm")) ~ " Nm").show();   
   Text_Line_L[6].setTranslation(40.0,ypos+120).setAlignment("left-center").setFontSize(22,1).setColor(1,1,1).setText("Leg Magnetic Course: " ~ sprintf("%3.2f", getprop("/instrumentation/gps/wp/leg-mag-course-deg")) ~ " degs").show();
   Text_Line_L[7].setTranslation(40.0,ypos+160).setAlignment("left-center").setFontSize(22,1).setColor(1,1,1).setText("Leg True Heading: " ~ sprintf("%3.2f", getprop("/instrumentation/gps/wp/leg-true-course-deg")) ~ " degs").show();
}
...


Note: I'm aware that the EFB Applications (...and other stuff, too) could be inserted into the relevant page's hash; I decided not to do it for readability (and portability: those Applications are consistent with the 777, and probably the code would result difficult to handle/modify/port)
Note 2: ehm...well, :roll: you will excuse my pedant use of Comment Lines through the code: being old, I rather prefer to easily identify sections at a glance, together with a few reminders...the old-school taught me to always try to make easy the reading of a code by Comments!)

So...that's the current status 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...

I'd like to get your opinion and advice on this first 'modernization': I hope that the EFB would comply - at least, a bit :oops: - with your request for portability.

Also, three questions:

1. - My very next task on the EFB has to do with all the Conversion Utilities; I wish to use - in this case - some small canvas objects (if you still have the old EFB on the Seattle, go to 'Pilot Utilities/Speed Conversion': see those 'romboidal' markers?...those are the ones I need to handle); they need to be animated (moved), turned on/off, pushed (by the mouse) and parse. I've read this: http://wiki.flightgear.org/Canvas_Nasal_API#createTransform, and I'd like to study some working examples for those Classes & Elements. BTW, could you clarify what is intended by " transformation matrices"?
2. My last task on the EFB will be to take care of Charts' handling: I will certainly clean-up the current code, but I need to study the matter first; I have seen the example you report in the last post of yours: as a graphic designer - please, don't feel offended - I do not like the visual outcome, but I do appreciate the handling capability. Any links/suggestion for learning (working examples, and coding)?
3. The idea of getting the Charts from airnav.com it's nice, but I have not an account on it (where&how can I get access to the Charts?); also, I would like to insert hi-res Charts. Further, it seems that there's not a definite point on Charts' use (source, resolution, STAR/SID/IAP procedures NOT inserted/handled into Route Manager :evil: , and so on): is there a kind of generally-agreed consensus among FG Pilots/Developers about a standard (or something sounding like that!) to be used for Navigation Charts?...if so, I would gladly comply with it (expecting that the same sort of standard, so to speak, is (will be) used also by other aircrafts); otherwise, I have to devise the better solution for the 777 together with Hyde. Being FG 3.2 soon to be released, I will postpone my study of Http's addressing later on.

Thank you very much - again - for your kind support and advice! :D

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sat Jun 21, 2014 10:29 pm

wow, I wasn't expecting that you had continued with canvas despite my suggestions to take it more slowly - when I said that, I was just trying to keep the workload low and to ensure that you'd do things step by step. But you seem to have made a lot of progress recently, including Canvas related changes. Did you work through the tutorials that I suggested earlier (regarding vectors, hashes and OOP) ? Or did you manage to make so much progress so quickly ?

Concerning your changes, they look good to me - but maybe there's a way to get this committed to gitorious so that we can take a "full" look ?
Did you introduce any regressions or do you think that Hyde could commit your changes to the 777-200 directory, so that we can have a look ?

I do like the fact that you started to use separate files to better modularize things, using shorter functions and helpers (classes/methods) is also a good thing!

Regarding your Canvas related changes: You seem to have this working now, but you mentioned a few weeks ago that you found the docs to be lacking/insufficient - thus, I would appreciate any pointers/help/advice to improve them accordingly - feel free to edit those articles. If you are having doubts, use the "talk" page to post your changes there, so that others can benefit from your feedback.

Regarding the SVG parser and gradients: I think that text can be separately handled via osgText (which should support gradients/AA etc), but I need to check the code to know for sure.

Moving pages into hashes is a good decision - note, that you can also turn those into full classes with methods, instead of just hashes - that would allow you to make those functions part of the actual hash, instead of some separate "free-standing" function.

Your page handler looks straightforward to me, and it seems you are now very comfortable with using vectors, even multi-dimensional ones ;-)
And very good job using loops to initialize clear your vector!

But you may still want to keep the design flexible enough, so that you can support other use-case scenarios at some point.

Also, it seems that reading up a little more on OO may help you generalize some of your code a little better - for example, it seems that your code is currently structured such that it only supports a single instance of your EFB ? Once you start using classes and objects, you can easily re-arrange your code to allow your captain/copilot to have independent instances of your EFB, so that they don't affect each other. In fact, you could theoretically have dozens of EFBs running concurrently. This may not seem useful or relevant to you at the moment, but it greatly simplifies coding in the long-term.
Gijs ND/PFD code had the same problem originally - but you will find that it is much easier to write generic code once you start using separate instances/variables for each "version" of your instrument (EFB).

If you'd like to learn more about using classes and objects (instance variables) to accomplish this, see this little tutorial: http://wiki.flightgear.org/Howto:Coding ... _Framework

Basically, the idea is to get rid of "global" variables, and instead use "instance" variables that are part of an outer scope (hash), such as:

Code: Select all
var EFB = {
 new: func(name) {
 var m = {parents:[EFB] };
 m.name = name;
 return m;
 },
 whoami: func() {
  print("EFB owner:", me.name );
 }
};

var CaptainEFB = EFB.new("captain");
var CopilotEFB = EFB.new("copilot");

CaptainEFB.whoami();
CopilotEFB.whoami();


(You can use the Nasal console to test this)
As you can see, your two EFBs will inherit from the same EFB class, but they will have their own private namespace - i.e. the "name" member in this case. It can be accessed via the "me" prefix.

Regarding your other questions:

#1) You can basically transform any group, i.e. by changing its scale/ratio, rotation etc - animations would be implemented by changing color/size/rotation through a timer for example, maketimer() should be used for those, ideally all through an Animation class that serves as a wrapper for all animation needs.

#2) The visual outcome of the 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.

#3) 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.

#3.1) That's a good question, but we don't have anything like that currently - a while ago, we talked about supporting XML files to properly geo-align charts.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby I-NEMO » Sat Jun 21, 2014 11:41 pm

Hooray,

thanks for your reply: glad that you somehow liked my small progress...! :D

Yes, I've read all the various pages you suggested: some of them were clear (just fairly clear, to be honest...), others were too 'cold' and/or un-complete (that is: unusable by a newbie as I am). So, I've tried to integrate the 'learning-curve' by the old-school's method: 'trials&errors"!
Regarding the FGWiki improvements: that would be another heavy job, and unfortunately - at the moment - I have no time for that (I have an heavy to-do-list waiting, as you've read). But, sooner or later I will try to add some notes on the relevant pages...

Regarding the .Git commitments: the whole code is still a WIP, and there are some errors - which would 'break' the EFB - not taken care of (at the moment) because I'm working by modules...so, I presume that it would not be a good idea to commit it 'as-is' right now. But I presume that in a few days I should be able to commit something usable&feasible. I'll send you a notice about that. I will consult with Hyde for the best solution.

Regarding OO: yes, of course I'm continuing to study; in my opinion, some issues are not clear at all on the FGWiki, as I said, but I'll keep going on studying...
And, Yes, of course I want/need to have two EFBs, so I do appreciate your hints: will study them and try to insert the needed mods to the purpose.

Regarding the group/elements canvas animations: you did not answer my question (what is meant with ' transformation matrices' [could you give me a properly explained example?])?
Also: can I apply animations to single canvas elements? If so, is there any coding example I may consult?

Regarding Charts: Ok, I'll read the suggested topic; should I have questions about it, I'll let you know.
And, I'll try to get and check the 'airnav' charts...

Too bad about the lack of a sort of Standard consensus for Navigation Charts: so, I'll decide with Hyde what would be the appropriate development from our side.
One thing which is REALLY missing to ALL FG aircraft, though (and I hope that someone might take quickly take care of) is the fact that STAR/SID/IAP Procedures used in Route Manager are not consistent with those you get through the relevant Charts; again a lack of standard (any standard would be ok; no standard means going just 'wild', and/or missing the point!)...

Thanks for your notes, Hooray!
Will keep you posted on further developments.

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 12:04 am

My last task on the EFB will be to take care of Charts' handling: I will certainly clean-up the current code, but I need to study the matter first; I have seen the example you report in the last post of yours: as a graphic designer - please, don't feel offended - I do not like the visual outcome, but I do appreciate the handling capability. Any links/suggestion for learning (working examples, and coding)?


It should be possible to procedurally render charts like these using Canvas and some custom styling:
http://wiki.flightgear.org/Airport_Diagram_Generator
Image Image

(the main advantage would be that these would be 100% in sync with actual FG nav data!)

  • once you have gone through several iterations of "trial & error", you'll arrive at something called "experience" :D
  • regarding the wiki, you can also easily add open questions "in line", so that we can take a look eventually
  • yes, please consult with Hyde to get your changes committed to git
  • re: open OO questions, please try to be more specific, so that we can provide concrete answers/examples
  • to support two/multiple independent EFB instances, you'll probably want to understand basic OO concepts
  • a transformation matrix is applied to to an element in order to transform (rotate/scale/translation) a canvas element, see $FG_ROOT/Nasal/canvas/api.nas @36 ff for details and links/examples
  • yes, transformations and animations can be easily applied to individual elements - preferably, you'll want to use separate groups for elements that are to be individually handled, the corresponding APIs are really anything that changes the appearance of a symbol, such as .setScale(), setColor(), setRotation(), setTranslation() etc, in combination with a timer to make the whole thing animated, or to toggle at least visibility of separate animation stages. An example can be found in $FG_ROOT/Nasal/canvas/map/DME.symbol where we're animating the symbol by changing its color/size through a timer every 500 ms
  • I would prefer such things to be handled by a separate wrapper class
  • chart handling, and geo-alignment, is something where transformations probably need to be understood
  • a "standard" for navigation chart handling should ideally be based on real avionics standards
  • inconsistent TPs are not so much due to FG, but due to a lack of data - i.e. we do not have access to the corresponding AIRAC cycles, and we don't have any system to replace our built-in navdb with the corresponding data/files currently. Thus, we're using outdated data - especially whenever people are using the latest "real" charts. So you really need to understand the problem to come up with a "solution"-otherwise, it's just uninformed guessing and poor coding that will come out of it. The "proper" way would be to support externally imported AIRAC cycles and use this data inside FG (i.e. navigraph).Otherwise, the only feasible compromise would be procedural chart creation using the actual navdata available in FG and creating all charts accordingly (see above).


regarding Charts: Ok, I'll read the suggested topic; should I have questions about it, I'll let you know.

viewtopic.php?f=3&t=22784&p=206788&hilit=VRT%20files#p206788

Regarding OO basics, see:

Subject: 777 EFB: initial feedback

Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 777 EFB: initial feedback

Postby I-NEMO » Sun Jun 22, 2014 1:26 am

Hooray,

ok, thanks...will go through the OO stuff and links.

Regarding the Chart issue: those Charts are not what I have in mind; basically, they lack of Lat and Long datas...and detailed graphics and infos.
At the time, Brisa did a very nice job with that Java application; but the actual result it's not what we're looking for: the Chart standard - for example - should include STAR/SID/IAP Charts, which have a lot of info and details used and/or usable by FG Pilots and ATC.
In a word: Charts have to be real.
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.
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'.
Of course, that's just my opinion.

Please, check a couple of real KSFO charts:

(source: airnav.com)
https://www.dropbox.com/s/jjm53laqwbqkfnf/00375AD.pdf
(source: the Web, I presume it's originated by Jeppesen)
https://www.dropbox.com/s/sqswo7fk64r3v9p/RR-CPAIR-KSFO-Airport-Diagram.jpg

I do presume that this kind of Charts too might be procedurally rendered using Canvas and styling (texturing and canvas objects' overlay).
As I said earlier, the lack of a generally accepted standard in FG (at the moment) will take our Seattle's Team to devise a possible solution; we'll of course try to take into account avionics general rules and so forth.
Anyway I'll discuss with Hyde what would be a fair starting point...an EFB (any EFB) 'plays' with Charts; and there are thousands of charts that a Pilot may need in his flight planning.
I would go for real charts (available on the Web), rather than producing again thousands of 'partial' charts.
I wish that someone else interested in this issue might share his opinion on this.

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Philosopher » Sun Jun 22, 2014 1:32 am

Please use/ask Hyde to use a separate clone (i.e. other than main) to push your work, like our canvas-hackers one, that way we don't worry about breakage.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: 777 EFB: initial feedback

Postby I-NEMO » Sun Jun 22, 2014 1:41 am

Vale, Philosophus Augustus!

...Sic naturaliter agetur! :D

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 3:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 6 guests