Board index FlightGear Development Canvas

canvas.draw library merged to FGDATA

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: canvas.draw library merged to FGDATA

Postby jsb » Tue Mar 10, 2020 9:19 pm

Thorsten wrote in Tue Mar 10, 2020 12: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:
  1. 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.
  2. If you like your framework and its interface is sufficiently stable, why didn't you publish it in FDDATA yet?
  3. I just scrolled through some randomly selected nasal files of the shuttle - to be diplomatic, I agree with your statment about coding preferences
  4. "swallow all the work" Don't worry, that won't happen any time soon.
  5. "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)
jsb
 
Posts: 259
Joined: Sat Oct 25, 2014 8:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: canvas.draw library merged to FGDATA

Postby jsb » Tue Mar 10, 2020 9:21 pm

wkitty42 wrote in Tue Mar 10, 2020 5:33 pm:2 cents from the peanut gallery:

there's no clear list of what's available that is easily accessible and up-to-date... plus terminology differences can make searching for some thing rather tricky... searching back through mailing list archives and hunting for wiki articles leaves a lot to be desired when different terms are used here and there... things are eternally recreated/reinvented because searches fail or because the thing being hunted for is not complete or readily available and easy to paste into a project... i don't know how to fix this or what to suggest...

/me grabs his coat...

Thanks :)
jsb
 
Posts: 259
Joined: Sat Oct 25, 2014 8:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: canvas.draw library merged to FGDATA

Postby Hooray » Wed Mar 11, 2020 9:27 am

jsb wrote: 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


I think that's actually a very good point, we do have some really clever code, but comparatively few people contributing to it - for instance, look at the MapStructure stuff, I believe so far it's only been added to by 3-4 people over the course of several years, probably because it's "too elegant" or rather "too complex" like you said.

And then there's stuff like the ND code, that's become a mess over the years, so that people end up duplicating/re-inventing things. For example, the E500 developers ended up reusing /some/ MapStructure concepts to speed up their MFDs (i.e. texture based symbol caching), rather than simply adopting MapStructure itself, and adding to it whatever is needed.
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: 11836
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby Johan G » Wed Mar 11, 2020 12:48 pm

Hooray wrote in Wed Mar 11, 2020 9:27 am:[...] probably because it's "too elegant" or rather "too complex" [...]

As a side note, those are mutually exclusive to me.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5791
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: canvas.draw library merged to FGDATA

Postby Hooray » Wed Mar 11, 2020 1:25 pm

Actually, a MapStructure layer/symbol controller is a fairly elegant/lightweight piece of code: https://sourceforge.net/p/flightgear/fg ... controller

In other words, this will accomplish a ton of things with very little code that isn't overly complex at first sight.

However, for all of this too work, the underlying framework is doing some pretty sophisticated things - in a sense, it's similar to Ruby on Rails, i.e. getting away with implicit assumptions that people can override if they want to, but otherwise something really simple will get you going within seconds, the following snippet of code will load an SVG file and animate it using a single property, to end up with a compass rose: https://sourceforge.net/p/flightgear/fg ... APS.symbol

Code: Select all
# Rotate with the main aircraft.
# Will have to be adapted if intended for use with other aircraft
# (but one could simply copy the layer for that).
var draw = func {
   var rot = getprop("/orientation/heading-deg");
   rot -= me.layer.map.getHdg();
   me.element.setRotation(rot*D2R);
};
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: 11836
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby jsb » Wed Mar 11, 2020 10:47 pm

What still drives me crazy about the Map framework is that it defines random file extensions and that the snippets in those files have no context - snippets becomes quite literal here.
What is a .symbol? What is a .lcontroller? The content of these two examples makes not too much sense on its own - one has to study all the other files to understand :)
-
At first glance, the canvas_draw.nas in the shuttle, at least the first 540 lines IMHO are not code but just bloated data that should have been written as a hash of vectors in the first place. So that does not compare to the draw lib that I've ported to fgdata.
On the other hand there seems to be a quite nice vector math lib hidden in coordinates.nas, why isn't this stuff in FGDATA/Nasal/math.nas?! It would be worth porting it to FGDATA so everone can make use of it.
Having spent some more time tracing through the files it seems that what looks like a bunch of "unknown" data in the first place drives what I know as "turtle graphics" (ploting). Which is quite cool and again, why isn't this stuff generally available in FGDATA?
I'd be willing to help porting such things into FGDATA but as always, this makes only sense if people are not only willing to use such libs but also are willing to contribute to them.
jsb
 
Posts: 259
Joined: Sat Oct 25, 2014 8:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: canvas.draw library merged to FGDATA

Postby Hooray » Thu Mar 12, 2020 8:54 am

jsb wrote in Wed Mar 11, 2020 10:47 pm:What still drives me crazy about the Map framework is that it defines random file extensions and that the snippets in those files have no context - snippets becomes quite literal here.
What is a .symbol? What is a .lcontroller? The content of these two examples makes not too much sense on its own - one has to study all the other files to understand :)

Indeed, your points are entirely valid. However, the framework is pretty well documented on the wiki.

That being said, MapStructure is all about an MVC design, i.e. you have classes that are responsible for the MODEL, the VIEW and the CONTROLLER.
Each map consists of "layers", each layer consists of "symbols". And each map/layer/symbol can have its own set up controllers.

*.symbol files contain the drawing routines (view aspect)
*.lcontroller files contain the controller for the map's layer
*.scontroller could be used to control individual symbols (think mouseover/tooltips), i.e. that's primarily useful for interactive stuff like UI dialogs.

The whole design went through several iterations, and the framework was also put together by taking useful stuff from existing work (primarily Gijs 744 ND at the time).
The goal was to support multiple instances of an instruments, to support different FDMs, arbitrary autoflight implementations, and also different "styles" of displays - ultimately, we also wanted to be able to reuse Gijs' work elsewhere, i.e. in UI dialogs (think map-canvas.xml) - that meant, that the logic controlling each map/layer/symbol had to be factored out, and made configurable - including styling/appearance. That is why the code is using so many delegates and "options" hashes.
In addition, we wanted things to be really modular, i.e. no more than ~30-50 lines of code per file - so that people could easily customize things.

This is how the current structure evolved, each of those files is dynamically turned into a proper Nasal class, and an object/instance - admittedly, it's using a bit of sophisticated Nasal fu to make that happen, but at least those goals were obviously accomplished - even though the number of contributors is probably still single digits only, it seems it's primarily core developers or long-term contributors with a background in CS/SE who feel comfortable adding to it - and maybe exactly for the reason that they don't need to edit Nasal code with hundreds of lines of code ;-)

I'd be willing to help porting such things into FGDATA but as always, this makes only sense if people are not only willing to use such libs but also are willing to contribute to them.


It's more likely for people to adopt something if it's well documented, that is why we started the "Canvas Snippets" article, and it's also more likely for people to get involved if there are channels/protocols to do so (aka someone willing and able to help with getting things reviewed and committed).

In general, a number of canvas early-adopters have created a ton of great code, which is often only available as part of their "aircraft" (think Extra500, space shuttle, and probably some others).
And then there are people who re-invent the wheel, because the learning curve to use what's there was simply to steep.

I think it would help to grow a library of useful modules by incrementally moving things to fgdata, and documenting useful stuff.
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: 11836
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest