we would probably have a very interesting time talking in person ... I mean, I am now inclined to prove even your last posting wrong by digging out the postings you made in the spaceshuttle thread asking how to animate the gauges (MEDS?).
please respect that there are different design goals and opinions. There's no need to create wiki pages to document how everyone else is doing wrong in my view. And if your response to me pointing that out is to call my coding abilities into question, then I guess I'm not interested in that particular branch of mud-wrestling, sorry.
this is not about being unable to accept different views - I can prove that the people working on the corresponding MFDs did want their stuff to be more generic, they just didn't prioritize their efforts accordingly (which also is fine).
However, it does make sense to provide the corresponding pointers/references for those interested in that kind of work - and since I-NEMO basically stopped working on the EFB code, and since Gijs and Hyde appreciated my refactoring their code a little, I don't think there's any harm being done by me pointing out that the R9 code is indeed much better in comparison but lacking abstraction to be reusable elsewhere.
My comments above regarding your coding style was not in response to you pointing out different views should be tolerated, but to your continuing claims to understand OOP and that it would be your decision to use it or not (which it obviously is), despite the corresponding codebase being de-facto object oriented Nasal code mapped to C++/OSG code.
Like I said, this was not intended to offend you - but you asked specifically something along the lines of "what is a SVG element", "what can I do with it" - someone who understands OOP could have looked up the parent classes, or even just could have used debug.dump(element) or debug.dump(node) to see for himself how a SVG image is mapped to a group/element which in turn represent a Canvas path.
That's the contradiction I was pointing out - you made a ton of valid remarks, but then you started the hair pulling, and none of it seemed to make sense anymore in the light of your questions, as well as previous admission not to be too familiar with Canvas internals (which also is fine), but once someone takes the time to explain the concepts you asked about, you start making a big fuss about all sorts of different things probably for the greater good, trying to protect fellow contributors
I don't think we need to talk about optional features in the case of an optional Canvas framework...
People were specifically interested in airliner avionics - I assumed, a CDU framework - shortly afterwards, everything went haywire.
If you disagree with any wiki paragraphs, quotes, articles, you are obviously free to remove them - hey, it's a wiki after all.
I would just ask you to consider that some people may actually appreciate having certain pointers - even if you don't.
And I don't think we necessarily need to be "done" here - it just seems that it may make sense to split this thread a few times, because we successfully derailed the whole thing