Hallo Hooray,
Thanks for your post; I was delighted to read it, and I do generally agree with your kind notes.
To respond properly to all your questions, as I would like, would imply such a long, really long, post that I thought more convenient just to sum up some basic points. [be warned though: my 'short' reply is quite long; I'm talking about Philosophy here, and a nice cup of tea might help to relax and get my points].
First of all, I'm the sole responsible for the current coding of the 777 Seattle's EFB. As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:
1) to do something to compensate for the lacking of an EFB inside the Seattle.
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.
It took me three full months (days & nights) to get to this horrible - but somehow working - first piece of code]. Reason: I'm old...! 
As I said, this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be.
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. I wish to learn nasal, even if when I read a piece of nasal written by you experts, it looks to me as weird as a mystical code.
[Note: please, consider my status as a newbie; I appreciate the concision of nasal, and it's possible efficacy; but it's not a clearly readable code; on the contrary - as it is for C++ - it lacks of immediate understanding, and it's in my opinion a very, very bad side; coding should be universal and easy to grasp, and not a specialist domain only]
So, I hope that I might be excused for the 'rude' coding by experts as you and other people undoubtedly are.
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...
And I wish to come now to a more important point, which - in my humble opinion - should be deemed fundamental by FG people, as it should have a much higher priority in the FG community's task-list than an instrument code.
FG is a very nice Project, I love it, otherwise I would not be here. I appreciate the overall philosophy underlined in the project.
But, again in my opinion, the major current fault of the FG project is that is a Work-in-Progress (an expert would call it a WIP)...which never reaches a workable, stable, state in it's core, inner parts.
Things do change continuously on all fronts, issues are never truly resolved once-and-for-all; I mean: it's absolutely normal and acceptable that some WIPs issues might live up for - say - one/two years.
It's surreal, though, that ALL issues are ALWAYS WIP.
A FG pilot, being him a kid or a senior (it's my case), and/or a developer is confronted with continuously changing issues. No concrete stability for a certain solution in reached. This makes the overall status of FG a nice playground for all of us, but at the same time it makes FG a nightmare to be followed (and lived like that, when developing) by a developer. All developers are confronted with uncertainty about current status of a particular issue, and available solutions are always to be considered partial.
Further, if you want to search for a particular, possible solution, or suggestion, or hint, about what the developer has to produce for his project, he is confronted with myriads of tiny pieces of code's snippets, dispersed all along the huge Forum, in the always uncompleted or obsolete or 'deprecated use' pages and so on...it's really frustrating, because you never find a decent, solid, starting point. That looked for starting point never has solid examples of coding, with detailed explanations of the single line of code; quite often, once you find something that might be (better; just 'sound') familiar and /or useful, you're redirected to somewhere else (I really hate wild-linking), where the author has a different approach, where the much abused words 'simply', 'easily', 'quickly' are on the opposite side of the real meaning of those words.
The reasons for this scenario are clear and unavoidable: FG lives on a wild-cocktail of competence, time dedicated to FG development, ideas, brand-new concepts, copy & paste projects, different views, different expertises, different goals, patches of all sorts, and so on.
FG is absolutely nice, I do appreciate it; but it doesn't really makes things stable and/or useful. In my feelings, FG is missing the first point: to possess a solid Standard.
Mankind likes freedom, but freedom should never mean that you do as you like. Unfortunately, that's our silly attitude on this planet of ours; we all love freedom, but freedom means also to take care of others, which usually do not live in the same situation, nor possess the same degree of instructions (please, see infra).
If we consider that a real aircraft flies because hundreds and hundreds of concurring minds have cooperated together on a particular aircraft project, following a strict timetable, for many, many years;
If we consider that a FG aircraft flies because of the care of a Shakespeare's 'band-of-few', ...may be twenty-thirty serious passionates !?;
Probably, we may understand why FG is as it is now: a continuous Work-in-Progress. Fascinating as it may appear this to some of us, I personally believe that it's quite surreal.
The main point is that - even in the happiest situation - an aircraft might enjoy some development (bad or good as it may be) when 2-3 enthusiasts decide to do something: (for the Seattle, Hyde and myself; reason: let's try (again: 'try') to make a better 777, aiming at realism whenever possible; BUT, a COMPLETE project).
In these conditions we should consider a miracle if we have a 707, a 747, a 777 and very few other aircrafts developed a bit. [I've always thought why on earth we should have so many aircraft models, 98% of them being totally 'primitive', and - which is worse - totally unsufficient on several issues].
Can miracles became more perfect?..Theoretically yes; practically no. There would always be a consistent degree of approximation, due to the reasons above.
We have to live with this. This does not mean that things might not be made better, of course. That's why I'm always eager to learn new things.
What I personally lack in FG, though, is a consistent and comprehensible Database of 'fixed' knowledge to develop an aircraft.
In Physics it's called, to elaborate - and then comply with -, a 'Standard'.
A Standard is a set of given Rules, a solid rock from where to start the development. This Standard should not change for a certain time; it may of course be enriched, widened, but each time someone puts a new piece of 'standard' onto the basic Rock, it MUST have been previously tested, shared, discussed and fixed; the new piece of Standard should have a life of at least a couple of years, if not even longer.
In my opinion, FG lacks this precise rock: we do not have a Standard.
We have thousands of issues, arguments, ideas, variants, patches, personal enhancements, semi-solutions, some of them even brilliant ones; but the FG 'rock of Standard' is very tiny, and changing too often (sometimes even daily!). A developer experiences a confusion of nice ideas, and lacks consistent, easy, and comprehensible reference.
About this, I will report my personal experience with the Seattle: reading around the Forum - where it is very, BTW, very difficult to actually 'find' something useful easily and quickly - I've been addressed to FGWiki; those pages, 90% of times, are - to me - like reading a mysterious parchment. I've lost my mind, and many hopes, on FGWiki.
FGwikis - a splendid opportunity for a beginner - are very badly written; like on the Web, finding something easily explained and 'told' - properly and thoroughly expressed, in depth - is a rare, very rare, occurrence.
People writing stuff does not have the slightest idea of what is required on their part to proper expose an issue.
This problem is named 'Communication'.
If you have not encountered this skill in your professional life, you write 'as you-think'; for the student/reader to actually enjoy the learning process, he has to be on the same wave-length of the writer (otherwise he is immediately played out of the game), and - what is more important and lethal - the reader who wish to learn something useful, practical, from the FGpages MUST already possess a factual experience of the matter. Which is evidently a paradox, not only semantically.
FGwikis are not didactical, at all: either you understand the same 'code-book' of the writer, or you're lost.
This happened to me with nasal: FGpages are NOT for beginners, many arguments and/or issues are reputed by the writer well-known by the student...and so, sadly, the game is over.
Many FGwikis pages are uncomplete; or considered as completed by who actually wrote them.
In my opinion, before writing something technical on the FGWiki, the writer should have a fair and consolidated experience in Communicating concepts, ideas, tips and tricks; examples are too technical and short, without any comment and /or explanations in common plain language, and do not take the reader with the outmost care along the process of learning [Please note: this is not typical of FG only; in fact, it's a general problem of the Web].
I speak from my experience: I do teach Quantum Physics (and Medioeval History !) sometimes, and my main concern is to write down what I know so that a complete beginner may follow the lessons; it's a very hard job, and even great experts consider the Communications task a most negligible issue: result is that the students do not 'remember' anything of what they - the teachers - have 'spoken out'.
Being myself a simple newbie on nasal (I have a degree in Physics), quite old (I started when the first Personal Computer was as large as a dishwasher machine!), I've of course learned several computer languages. No one denies the utility of C++, and stuff like that; but if I want to learn nasal, I quickly discovered that FGWiki's pages on that were written as ancient Aramaic texst, not helping me as I would have expected.
So, I did it on my own, well aware that my coding would result in a real mess...
Knowledge, at all level, in all worlds, is a matter of Communication.
My opinion is that Communication is totally ignored by 90% of FG community.
Now, let me conclude with a brief note about 'portability'.
I consider the issue important, but a bit utopian: we may 'port' something with a certain amount of success, only once the 'Standard' (see above) is set, stable, applied by all, and - moreover - respected by both experts and newbies. There are other major requirements for portability, but for the sake of simplicity I would skip this.
Now, the Seattle team (2-3 people, remember this, please) considered since the beginning that we would have made our best effort to respect the Boeing 777 manuals.
Ok, so then we studied them (BTW, many FG pilots would like to have an aircraft to behave as they 'think' it should behave; on the contrary, a Pilot should fly a 777 simulation as Boeing 'thought' it to be flown, possibly adding the unavoidable limits posed by the possibility of FG simulator's core software). You need to study first, if you want to fly and/or develop an aircraft.
Now, coming to the EFB, the EFB manual is made by Jeppesen for Boeing, and a particular ('vertical') approach must be considered by the casual developer (myself, in this case). Many functions devised by Jeppesen for Boeing are not easily simulated in FG; so - for the moment - I decided to skip them, and I concentrate on what I considered nice and/or useful (again, it's of course a matter of opinion).
[Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective]
As I said above, my aim was to give the Seattle's Pilot the feeling of a 777's EFB.
I doubt that an Airbus might have been developed using the same Boeing's EFB. The reason is easy: the two aircraft were 'thought' differently by the actual engineers, and both Boeing and Airbus would have - not only possibly used different graphics - but also different software behavior.
Certainly, if Jeppesen was the EFB contractor both for Boeing and Airbus, Jeppesen's engineers undoubtedly used the 'standard' core of one of their EFB; but then, almost immediately they 'adapted' the EFB functionality so that Boeing and Airbus expectations could be respectively satisfied. At the end, we have two differently behaving tools (they do obviously interface to their respective FMC and instrumentation, which - again - works differently). Not to mention further applications added for newer versions, stemmed again in time by Boeing and Airbus.
Anyway, I looked around: I found Omega95's EFB from the 787 Dreamliner; I've studied it, 'thinking' that it could be considered as a good starting point (I somehow considered that 'that' piece of nasal was already considered as Standard and/or portable by the FG's community. And - again in my opinion - I considered that some of the logic behind Omega95's nice piece of software should have been adapted to the current Seattle Status; and I've tried, with my bad knowledge of nasal, to make something...functional. (it was Hyde's brilliant suggestion to use hashes for the airport data; but, I want to take those lines out of efb.nas, so to have a sort of easily accessible sort of DB; I have read that the solution to separate 'parts' in nasal may be obtained by using _set_listener, if I'm not wrong; again, not many quick and easy documented examples on how to use it)
[BTW, I've asked why I cannot fly Omega95's 787 in FG 3.0; it's still a tricky unresolved mystery why I was not able to load it (FG, .Git, Omega95 hangar; no response has ever come up from the Forum on how to make that 787 to work properly - and EASILY - on Fg 3.0)]
You ask in the title what is the current Status & Plans for the 777 Seattle: I would respond that we're working hard, making our best effort to 'complete' ALL the aircraft modeling. Which is an enormous task for 2-3 developers for such a complex aircraft as the 777; if you add to this that we have no 'standard' set in FG, that information is dispersed in at least 10 different sources, that those tiny pieces are partial, not fairly understandable, that quite often actual Communication skill is considered as an option (if not even neglected) by the experts, and that Canvas is still under development (I do like very, very much, the basic idea of Canvas; but - again - it has not reached yet a stable, consistent and EASY to apply status; you're certainly aware of the problem arisen from a further work on the Map structure, I believe, which actually 'destroyed' the 777's ND functionality for a certain amount of time)...well, you may perhaps understand how disoriented I may appear when I read your notes about the evident lack of 'portability' in my ugly piece of nasal...!
Nevertheless, I do agree with you, Hooray; I will gladly follow any working suggestion, and appreciate any real help in fixing the EFB; but, please, do consider that:
We want to have a Boeing 777 EFB (The device is already obsolete; real pilots now use other fancy devices on board).
It must be easy for a developer to actually use such an help.
It should be a quick and daily help, because - on my side, and being just two or three people - we want to achieve a FINAL release, passing of course through a WIP; I have other stuff to put hands to (fuselage, Flight Control Surfaces, Landing gears and so on).
The expert should have a lot of patience with me, because on nasal I'm a dumb kid; I can learn easily, though, if you take care in fully Communicating (see above) the issues consistently and with the outmost care for details. Step by step.
Please do NOT send me browsing for Pages on FG wiki and/or GoogleCode; those are reference's pages written most often in ancient Aramaic, and totally not useful for learning; those contained there are just statements by the writer, not communications aimed to teach something; they are simply not 'efficient', if you get what I'm trying to express. [Again, I cannot really learn anything useful and replicable from this: http://wiki.flightgear.org/Howto:Adding_a_canvas_to_a_GUI_dialog. The writer does not Communicate; the reader is easily unsatisfied, because there are no explanations of the single lines of code, there's not a working 'portable' example to be for instance included inside its project, and the overall technical philosophy is omitted; further, a lot of stuff is said to be 'phased out', and a beginner does not know how to integrate a 'dialog' inside his new project: It may appear pedant to the writer, but - with all due respect - I consider that page a perfect example of a surreal explanation]
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.
(Further Note: not that I do not estimate the value of portability; but I'm not paid by Boeing; I'm a passionate of Flight, as you certainly are too; It would be nice - I presume - to have a 'portability' FG Team, which could work in making that 'rock of Standard' more and more solid. But this, again, is an utopia))
One final note about Charts: following Omega95's achievement, I spent a whole month working on Charts (STAR, IAP, SID, APT) by finally devising a workflow based on Photoshop and other graphical professional stuff in order to get hi-res charts (check for instance LOWI and KATL), so that the zoom-in and pan functions might be used by FG Pilots as in real aircrafts. Once I got through the very first phase of that graphical workflow of mine, I casually discovered the discussion about STAR in the Route Manager, and the issue about using a certain standard (I cannot remember the name at the moment). I read about the usual GPL restrictions, about access, and so far. What really upset me, though, was to learn that for a STAR Chart to be included inside Route Manager, further programming is needed on the RouteManager code; if I'm not wrong, nothing has been made about this since months. I told myself: why have you been so dumb trying to make nice Charts available on the 777's EFB, if a Chart cannot be available to the FG current software? Should we also - the 777 Seattle's Team - take care of the RouteManager too? Why no one has been taking care - from his own side - to set up a 'Standard' (I mean a working standard) which can be activated by simply setting a 'flag' inside the RouteManager code? If i'm not wrong RouteManager is out there since at least a couple of years. Why it has not been completed?
This is again what I mean by the lack of stable, essential, Standard: and reading a casual pilot conversation while flying with an ATC controller, they both calls for Charts to be used for correct approach procedures, but ...thye get them outside FG!
I read that you would propose to access the internet for Charts, by setting up a Chart Server; I humbly disagree: Charts have to be available - as three standard Databases, for instance - locally; my experience with the latest Terrasync server on FG 3.0 is awkward: 45 percent of my normal flights in Europe or elsewhere are currently affected by a nice message by Terrasync, just telling that there are 'errors' in communicating with the server (and, YES, of course, I have a very fast and stable connection); and, what is even worse, there is no possibility to reset the Terrasync connection from within FG: you actually have to close FG, then launch it again, and just 'hope' that the Terrasync's connection does not fail!
I've looked on the Forum, and found the usual sequel of personal experiences, patches, command lines, take this out, take this in, and so forth. Why on earth the authors who rightly introduced the new Terrasync feature into FG 3.0 are not solving 'once-and-for-all' the issue?...
[Note: I love to work with Hyde, because once I report a possible problem that is related with his skills, he does not make statements: he says 'I'll fix it'; and after a few days it's fixed, once-and-for all. As a counterpart, I have the same attitude for his reports related to graphicals stuff. Moral: things need to be fixed !?...ok, fixed.]
So, Hooray, I would love to be able to access the Web (for instance to get a 'fresh' TAFF forecast from Noaa (string decoded)), but easily and without any problem whatsoever; there are quite a lot of opportunities out there.
I've tried to learn how to implement a communication on the Web: again, the impact with FGwiki and/or the Forum was frustrating: no solid, easy, crystal-clear example is given...so I abandoned it.
So please, Hooray, if you feel like helping developing beginners as I am (of the old school, though! 
) to produce something useful as you rightly expect, try to draw up something with your expert colleagues which may really help us to start from a stable rock of Standards; do establish them, gear them up, and publish them as the FG Bible/Koran/Rig Veda!...and, please, keep them unchanging for a human-time!
Then, very gladly, I'll be in a position to certainly comply with portability's issues.
Please do forgive the length of this 'short' post of mine 
: I deemed expedient to draw your attention to some views which are possible underestimated by the experts.
And for the 777's EFB, - if you have time, disposition and understanding of my position - let me know how, where and when to start: I would absolutely love to learn; but to learn, not just to read statements.
Should this be the case, you certainly may also use PM and/or Email if you feel like.
Thanks for your patience.
With all respects,
I-NEMO
Statistics: Posted by I-NEMO — Mon Jun 02, 2014 10:52 pm