Thorsten wrote in Tue Mar 10, 2020 1:56 pm:but I really would like to see what I've missed here.
What you missed is apparently that there is an existing framework to draw canvas stuff
Clearly I have my coding preferences ('lean and mean' I'd describe them), clearly you have yours - but would there have been a chance to fond common ground and contribute to the same framework?
You can of course re-implement and swallow all the work I've done into your module, but this won't solve the problem that I will still advise people to use my framework and you will advise to use yours, with the end result being lots of confusion.
What really disturbs me is the growing tendency of contributors not liking the existing framework/API/code/whatever and opting instead to code their own - which of course means we'll eventually end up with as many frameworks as we have contributors. At which point maintenance of the core will eventually be a mess, because of course if we have to fix things we don't have to fix them in one place, we have to fix them in several different frameworks - which in the end try to solve the same task.
Not commenting on your obviously bad mood, but some points you may or may not want to think about:
- a framework that is "hidden" in any aircraft or spacecraft is NOT available for re-use. IMHO a framework...
- must be stored in FGDATA so it is shipped with FG and is generally avail to any AC developer (and no, an addon does not qualify here, as it has to be downloaded by the user, which means it is not generally avail)
- must be documented in a way that allows "easy use" - I personally prefer Wiki because you can easiely link to other relevant information but inline comments or a well formatet readme.txt is also fine
- should be implemented as module if it is "kind of heavy" / used by a small number of aircrafts etc.
- If you like your framework and its interface is sufficiently stable, why didn't you publish it in FDDATA yet?
- I just scrolled through some randomly selected nasal files of the shuttle - to be diplomatic, I agree with your statment about coding preferences
- "swallow all the work" Don't worry, that won't happen any time soon.
- "not liking the existing ... coding their own": I can only talk for myself but this kind of "liking" is nothing personal but a matter of quality of existing code and documentation! If code quality is poor or code is too complex and documentation is not sufficient to understand "the hidden beauty and genius" of that code - well tought! - I cannot use it. Other way round, I would not blame anyone for not "liking" (using) my code for this reasons. (btw that is why I do not really like to publish my WIP early without any docs written)