Board index FlightGear Development Canvas

777 EFB status & plans ?

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.

777 EFB status & plans ?

Postby Hooray » Sun Jun 01, 2014 3:21 pm

Referring to Hyde's latest 777/EFB commit: 521d9dba704377ac7bf07aa41074e7b880cfd212

Image

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:

http://wiki.flightgear.org/Canvas_EFB_Framework
http://wiki.flightgear.org/Canvas_MFD_Framework

Functionality-wise there seem to be a lot of corner cases handled already by the efb.nas file: https://gitorious.org/fg/fgdata/source/ ... al/efb.nas
But especially event handling and mode switching is extremely explicit and non-generic at the moment, a problem that the original GPSMap196 code also had - the whole thing could probably be reduced by about 60% if we could work out a way to find common goals :D

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.

So who was involved in writing the code and who is working on it currently, and can we work out a way to generalize this so that this can be easily extended, but also so that it can be reused by other aircraft/developers, including different types of EFBs ? What are you working on, what are your plans - where do you need help ?

The basic recipe to make this sufficiently generic is basically what we did with Gijs' original ND code:
  • supporting multiple independent instances/instruments
  • supporting different aircraft
  • extracting useful code and generalizing it
  • integrating the whole thing with existing instruments (ND, PFD, EICAS)

Don't get me wrong, looking at efb.nas it must have been a lot of work - but if people would communicate a bit more, we could actually team up to help each other - there clearly is overlapping functionality in similar efforts like the ND, PFD, EICAS, CDU - and even the GPSMap196. As long as people code without communicating upfront, there's little we can do to help, short of rewriting major portions of code, which typically renders the whole thing incomprehensible to the original developers.

I'd really like to avoid having another dilemma like the extra500/Avidyne Entegra situation where the developers are basically re-inventing useful stuff in a non-generic way using a copy&paste approach instead of proper encapsulation and code reuse.

Whenever we start coding without communicating first, we're not really coordinating things at all, so that we may be doing redundant work, or cause wasted efforts through a lack of teamwork. Given the lack of manpower we have, we should clearly try to avoid such situations :D
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB status & plans ?

Postby sa7k » Sun Jun 01, 2014 3:42 pm

I think they also mistakingly uploaded some files that are not compatible with the GPL.
sa7k
 
Posts: 382
Joined: Fri Mar 16, 2012 2:24 pm
Location: SA7K
Callsign: LV-EPM
IRC name: sa7k
Version: git
OS: debian

Re: 777 EFB status & plans ?

Postby I-NEMO » Mon Jun 02, 2014 10:52 pm

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! :D ) 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 :oops: : 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
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB status & plans ?

Postby Hooray » Mon Jun 02, 2014 11:55 pm

Hi, thanks for getting in touch, and thank you very much for such a detailed response.

I don't think the code is "horrible" like you say - it is normal for complex code to go through several "iterations" (versions) that are generalized and improved over time. Just look at some of my own Nasal code, it also isn't perfect from the get-go (if at all). I think it's great that we have someone interested in doing EFB development and in learning more about Nasal. I wouldn't be too worried about Nasal knowledge per se - it is more important to "release early & often" so that other contributors can provide feedback and code snippets, which you can then apply over time. That is also how the NavDisplay framework took shape, and how the GPSMap196 is being developed currently.

Like you say, it is unfortunate that we don't have more people interested in exploring EFBs via Nasal/Canvas, but this is also a great motivator, and it is also a good opportunity.
The lack of certain features keeps motivating us to contribute to certain projects - and I am definitely interested in helping with your EFB work, but given a number of other efforts, I'll have to focus on providing code snippets, feedbacks and maybe a few custom tutorials about Nasal and Canvas, if that's okay with you ?

Regarding the state of the current code - yes, there's some room for improvement obviously. But it's not so much "horrible" as it is too "static" - it is impressive that you managed to write all that code within just 3 months. And it's a great testimony to Nasal accessibility, and your ability to learn Nasal in the process, that you came up with working code. Thus, from that standpoint, you have already accomplished much more than most people who never even dare to touch Nasal, who say it is too difficult, and whose ideas really never become actual features.

What you have now is an actual feature that works :D , and while there are some technical problems, we are here to help you, and we can provide feedback and code snippets that you can use to improve the code over time. So I really wouldn't worry about the quality of code too much, it is more important to have something that works, than some perfect concept that never becomes a feature.
We usually say "the perfect is the enemy of the good" - and you have already come up with something that works well enough for your needs, so we can now try to optimize the whole thing.

Frankly, I don't think most people -without a programming background- would be able to learn Nasal and produce a working EFB system, no matter how much it may suffer from certain design shortcomings. We have other examples in FlightGear of inelegant code that still gets something done - and obviously that's superior to elegant code that never actually works.

I am sorry to hear that you find our Nasal code a bit obscure at times. But let me say this clearly: Sometimes even the experts are having a hard time to understand code written by other experts. For instance, I usually need some time to work through TheTom's, and especially Philosopher's, code - even though it is very elegant and well-structured, it is usually fairly sophisticated. And there are even core developers who are not using Nasal/Canvas because they're having a hard time with the accessibility of Nasal code - so you're not alone here, we've all been there once ;-)

Then again, it's great that you say that you're interested in learning more about Nasal - and I think we/I can help you with that. Obviously, it would be good to know a bit more about your programming background, even if that just boils down to a few Nasal tutorials that you worked through, or others that you still find too difficult. For example, understanding OOP is really useful when it comes to working with Nasal/Canvas, and especially creating frameworks that are supposed to be reusable.

You mentioned C++, are you familiar with C++ ? If so, I am sure we can provide a few pointers on common C++ constructs and their Nasal equivalents.

So, I hope that I might be excused for the 'rude' coding by experts as you and other people undoubtedly are.

Like I said, no need to apologize at all - most "experts" also once had to get started somewhere, and it is normal for programmers not to be proud about their code, even just a few months later.
So your attitude sounds very healthy to me - an "expert" is someone who's often already failed tens of thousands of times in order to reach proficiency ;.)
For example, there are probably a handful of "Nasal experts" around here, and we can still learn from each other - in fact, getting my code peer-reviewed by people like Philosopher is a real learning experience. Most of us simply don't have such internals knowledge, so we should embrace the opportunity.

It's surreal, though, that ALL issues are ALWAYS WIP.

I don't know what exactly you're referring to here - but please understand that most of us started out exactly like you: contributing some feature, and being interested in other stuff at the same time - so we gotta make concessions all the time. If you haven't already, I suggest to check out the "how the project works" and "implementing new features for FG" articles.
Indeed, by many end-users, you would now be considered a developer due to your EFB work - especially by those who have never touched any Nasal, and who have no intention to do so (ever!).

No concrete stability for a certain solution in reached.

Backward compatibility is indeed a problem - but it is not easily solved, to see what I mean, check out this: http://wiki.flightgear.org/Implementing ... onsistency

And yes, your EFB code contributes to the whole problem obviously :D

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.

that is generally true probably - but I can foresee other contributors saying pretty much the same thing when stumbling upon your EFB.nas code (or even most 777 coding) - so it's a problem that is inherent to FG in general, and which isn't solved by discussing it here - to change something, people have to be the change - simple as that.

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.

The funny thing is that I am getting such speeches almost each week - for some reason people must be thinking that I can do something about that !?

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

right, freedom in FlightGear is causing some very real challenges - and that is exactly the reason why I am speaking up when I see stuff like your EFB code, but also redundant stuff like the Avidyne Entegra R9 mapping code. Again, it's not fun for people to work in a more organized fashion, look at the explanations provided at: http://wiki.flightgear.org/Implementing ... onsistency

Still, I do applaud you (and the remaining 777 team) for teaming up and working towards a common goal - like you, I do consider all those unfinished aircraft to be problematic, and a waste of manpower/resources.

Regarding all your comments on the quality of the wiki, I don't even disagree - I think I once felt like that, too - but I got involved in the wiki and tried to be the change I wanted to see, and according to the wiki logs, I belong the 10 most active contributors meanwhile. So it isn't impossible to improve things. In fact, the wiki used to be much less accessible a few years ago, it was all thanks to Gijs and people like Johan_G that we now have a pretty useful wiki.

But I do think that many points you are making, including the one about our wiki, would be better discussed in a separate thread.
Most people interested in Nasal/Canvas will just look for questions that they can solve, they don't want to get involved in lengthy debates about key problems - and in fact, the way you are responding now, you are obviously a part of the problem, not the solution ... :-)

I suggest to report your posting so that a moderator can split it up (ask Gijs, I cannot do that myself).

I am sorry that you found the Nasal docs hard to navigate/grasp - but like you said, it's something that must be considered "in-progress".
People like Philosopher and myself are constantly trying to improve things there - but obviously that's much less "fun" than doing real work, like the MapStructure framework, the REPL console - or even an EFB !

But hey, it's a wiki - people CAN get involved, and if they cannot improve things, they can at least ask questions to point out missing information.

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.

with a degree in physics and a background in teaching, you could surely point out what is missing in your opinion, ideally using the wiki itself, and not the forum ?

Technically, it is in my opinion too short-sighted to focus on the differences between Boeing and Airbus aircraft, or to consider FlightGear's lack of VNAV support a show-stopper. There are certain building blocks that WILL be required either way. Even if it's just MFD management, i.e. button/switch, mode and page handling - that will be generally useful, regardless of the concrete manifestation of an EFB.

I do think that part of the problem is that your work was inspired by omega95's work, which really was far from being generic right from the beginning - it would have been better to discuss the requirements here and ask for a few snippets and apply some feedback - just look at the GPSMap196 thread, and how much progress F-JJTH has made within just a few days, and most design limitations are now gone, and there are enough stubs/placeholders to generalize the thing sufficiently.

Regarding the hashes at the of efb.nas: you can use io.include() to keep those in a separate file.
What you are referring to regarding setlistener are so called "Nasal submodules" (see the wiki for details)

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)

I believe that to be inaccurate - shortly after Hyde and others reported the issue, I posted a one-liner patch that fixed the issue COMPLETELY - it was just never committed, and for some reasons fgdata/777 maintainers no longer feel responsible to help with such things. I don't commit directly to fgdata either - so yeah, it's a chicken/egg obviously.
Overall, I believe the Canvas/MapStructure issues to be very minor here in comparison - and all the rambling on backward compatibility and stability is apparently colored by stuff that omega95 and redneck have been spreading for years - and to be very honest, the whole problem is not due to FG making "too much progress" or due to FG "being too unstable" - but due to people coding in a way that isn't future proof at all. Most of the 787 Nasal code qualifies here unfortunately, I happen to be familiar with it - including some of their other code, because I provided plenty of feedback, code snippets and tutorials in the early days, but obviously the outcome was still primarily supposed "to work" and not to be maintainable in the long-term.

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

I don't think I said anywhere that it's "ugly", but I did provide specific examples on what's needed to avoid certain "lock-in" issues, such as those that people experienced when using the 787.
It is unfortunate that omega95's EFB served as a reference here without you getting in touch first - we could have probably saved you 60% of the time, reducing your code by about 50% and making it 3x more generic in the process. Which is all I was trying to say.

And quite frankly, I am still reading through the rest of your response (which IS interesting), but even just reading that you came up with a process to use omega95's approach sounds unnecessarily redundant to me, and there are people around here who could have provided pointers to save you a ton of time - just look at the most recent EFB/Canvas thread where some came up with a script to create those charts procedurally, i.e. in an automated fashion. And there are more of these examples - working in isolation and complaining about the degree of frustration resulting from that is obviously going to cost people a lot of time.

Seriously, you are covering roughly a dozen different issues/problems in your response here - apparently thinking that I can fix all of those just by being aware of them, but unfortunately I can't !!!
There are quite a few issues that would be better reported via the issue tracker (especially route manager stuff, and other missing/broken things).
And to be honest, I am not exactly the right audience for all of your criticism here - for some reason I am getting such speeches almost "daily" meanwhile, often times in private, by PM.
But I cannot really do anything about such things, short of telling people that they have to stop debating and discussing such problems, and instead try to be the change they want to see.
That is exactly what I have been doing for years - and it's working well enough for me, and others.

Regarding the chart server, good that you are aware of it, interesting that you disagree - but this is not black & white - this has nothing to do with TerraSync, and as you may have noticed, I also proposed a non-server based solution, or at least suggested to use an integrated chart server, that would be running inside FG.

Concerning all the other issues you mentioned (forum/wiki communications), those should better be separate threads, or ideally even dedicated wiki articles, because they're not solved overnight, it's not a simple question that can be answered YES/NO unfortunately.

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.

Honestly, I do not mind the length - but I would have preferred for this thread to be about "one" thing only, no matter how interesting/correct and appropriate those other issues are - I am far from being/having the solution here, no matter how much I, and others, may agree with you. We can really only change things through our own work.

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.

I'd prefer using the forum or even wiki for that - but first of all, I should probably better understand where your wiki related problems originated from, feel free to use a new thread for that.

And yes, I did read the whole thing :D
But now you have created a new problem: Whenever someone else searches the forum for EFB related thread, they'll now find our monster responses here, and they surely won't bother to get involved then. So I guess to distill this a bit and create a new thread. This one is covering far too much stuff now.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB status & plans ?

Postby I-NEMO » Tue Jun 03, 2014 12:44 am

Hallo Hooray,

delighted by your response, quick and positive: I do appreciate it very much.

So, I'll try to get in touch with Gijs to see if he agrees on splitting issues in different threads.
And...ok, I'm ready to start from scratch; I only pray you to be patient and clear as much as you can...

No, I do not have a deep knowledge of C++, being too old when it came out (at the time I was busy with other stuff).

So, I assume that a fair method would be to deal with code sections:

Page Handling parser; what would be your advice? Could you give me some working examples - consistent with my actual EFB framework - to be tested inside my code?
I would test them, study them and come back with deeper questions and so forth.

Then, 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.

Once I will grasp this firmly, 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...

How about that?

Thanks Hooray,

Regards,

I-NEMO

Note: you have probably noticed that the Text object matrix is made by about 20 lines of text (to be consistent with some added applications, like the Descent Rate calculator, I had to add some more lines with different horizontal, vertical position on the screen, and different Font Size).
The piece of .xml code (EFB_display_lines.xml) which handles a given line of text (taken from Omega95' software) is quite large; so, I splitted the .xml related to all the text lines from the main EFB xml.
Still, I do not like it at all: is there a better solution for that?...the ideal would be to have just one piece of code to display a line, and a bunch of, say, 15 variables for all the various text properties (positions, alignment, font, font size, character size, and so forth); can nasal pass these variables to .xml withour addressing each time a setprop call? Or, even better: can we avoid .xml coding for the text matrix, and handle it from within nasal?

Note 2: procedural charts; I don't like the idea at the moment: I've seen some tests you proposed in the developmnet of the 'Airport Location' dialog: looking at Boeing manuals we want to stick to real charts, hi-res, full of details for the pilot; we just want to display a crisp nice .jpg, or .png, or svg, file on the screen (Boeing 777's EFB has a fixed ratio of 1.412371 proportion between width and height); a nice possibility, though, would be to superimpose some symbols over those charts, in time)
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB status & plans ?

Postby Hooray » Tue Jun 03, 2014 12:53 am

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.

I have provided some feedback/examples here: viewtopic.php?f=71&t=23204

Given the two first questions you are posing, 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.

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, see this demo video:

http://wiki.flightgear.org/Canvas_MCDU_Framework


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 (see the following screen shot, the raster image could also be a PNG or PDF file): 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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB status & plans ?

Postby Philosopher » Tue Jun 03, 2014 1:11 am

ego gratus sum, quod hic dicimus ;). (hic as in the adverb...)

I'll probably respond later when I have something more specific to contribute....
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: 777 EFB status & plans ?

Postby Hooray » Tue Jun 03, 2014 1:14 am

Indeed, sometimes it is amazing how difficult discussions can start becoming constructive again, I guess psadro_gm and wlbragg served as excellent role models a few days ago when they apologized to each other ! ;-)
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: 11354
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest

cron