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.

canvas.draw library merged to FGDATA

Postby jsb » Mon Mar 09, 2020 9:26 am

Hi :)

parts of the CanvasDrawDev addon have been merged to FGDATA so the library will be available with the next FG release by default and is available on next now.
See documentation at http://wiki.flightgear.org/Canvas_draw_library

Happy coding :)
jsb
 
Posts: 265
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 Thorsten » Mon Mar 09, 2020 11:13 am

I'm somewhat dismayed that we never manage to co-cordinate these things - now we have to my knowledge three (!) independently developed and maintained canvas draw frameworks.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas.draw library merged to FGDATA

Postby jsb » Mon Mar 09, 2020 11:46 am

oO
Well, that is interesting, where would I find the other two I don't know about yet?
Are they documented in the wiki?
Are they part of FGDATA?
jsb
 
Posts: 265
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 » Mon Mar 09, 2020 8:46 pm

See the shuttle draw api and rleibner's work, both were previously mentioned here on the forum, and I believe Rodolfo's work is separately documented in the wiki
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: 11896
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby jsb » Mon Mar 09, 2020 9:05 pm

Actually I more or less just ported Rodolfos work to FGDATA so it can be used everywhere and not only in specific add-ons. I believe this something good, no?
So this is not really something new and it has been around for over a year in the CanvasDrawDev addon so not really a secret project or anything...
If anybody had been interested to contribute, there had been plenty of time to do so.
jsb
 
Posts: 265
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 Thorsten » Tue Mar 10, 2020 7:33 am

If anybody had been interested to contribute, there had been plenty of time to do so.


Yes, and if anyone had been interested to contribute to my efforts, there had been even more time, because they predate all else (and yes, this is on FGData as well and has been for a while).

So the (for me) disturbing trend is that no one really sees a reason any more to contribute to existing efforts and prefers to do his own thing. Which in a way is how OpenSource works, but which is also why we continue to confuse aircraft developers who want access to some technology, because of course I will point people to my canvas draw tools which I understand, you will do the same for yours, so now we've introduced competing standards. And of course we all like our own standards best.

Same issue with 'how to use modular Nasal' - three different standards by now.

Animations got almost equipped with a re-implementation of property rules till I managed to point out in time that this will only make things confusing and not provide any new functionality.

Whatever happened to 'we annouce our plans on the mailing list and discuss them' so that - as a project - we may achieve some form of coherence?
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas.draw library merged to FGDATA

Postby jsb » Tue Mar 10, 2020 8:02 am

Would you please share a link to your work? I did not find anything on FGData but I really would like to see what I've missed here.
Thank you
jsb
 
Posts: 265
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 » Tue Mar 10, 2020 12:30 pm

I think there's nothing wrong here, it's actually good to have someone willing and able to review/integrate all the different approaches we have meanwhile, there are so many different concepts, ideas and structures involved, that it does make sense to have some kind of "maintainer" and look at existing work to see if, what and how things can be reused. I believe the shuttle, but also other complex aircraft featuring canvas based avionics (think extra500) contain a ton of useful code, and being able to reuse some of that would obviously be awesome.

Besides, whenever multiple instances of an instrument are involved, and whenever performance becomes an issue, it makes sense to come up with a layer approach, akin to a "framework", to have some lower-level library of "2D drawing primitives", and higher level helpers for creating avionics, as well as certain kinds of avionics, possibly with a pre-created library of elements (think altitude/speed tapes/laders, artificial horizon, compass rose etc)

Ideally, such a library would work out of the box, but also provide support for customizing things, i.e. using delegates to customize styling/appearance, but also heuristics as needed.

Thorsten kinda hit the nail on the head when he said, that there is unfortunately a growing tendency to re-invent the wheel, often at the aircraft-level, rather than the library/framework-level - so this effort is certainly one step into the right direction.

So it would be good to have a maintainer to review existing code and see how things could be better reused, by generalizing useful code and extracting it into a dedicated framework/library.

Regarding Thorsten's work in particular, see the topics linked below:

Shuttle 2D drawing helpers / G1000 effort ?

Plot2D and graph helpers

Hooray wrote:Thorsten's work can be found here: https://sourceforge.net/p/flightgear/fg ... idgets.nas
I don't believe it's currently documented anywhere though - you may be able to find examples in the shuttle repo.

Here's the routine setting up hotspot-specific tooltip/cursor handling:
Code: Select all
setContextHelp: func (f) {

         me.frame.addEventListener("mouseover", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'left-right'}));
         f("mouseover");
           });

         me.frame.addEventListener("mouseout", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'inherit'}));
         f("mouseout");
           });

         me.fill.addEventListener("mouseover", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'left-right'}));
         f("mouseover");
           });

         me.fill.addEventListener("mouseout", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'inherit'}));
         f("mouseout");
           });
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: 11896
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby Thorsten » Tue Mar 10, 2020 12:56 pm

but I really would like to see what I've missed here.


I think we're still talking past each other, but...

What you missed is apparently that there is an existing framework to draw canvas stuff (I announced this properly on the mailing list, and later I had a longer discussion with James about the virtue of SVG vs. procedurally drawn canvas HUD, so it was out in the public).

What you then missed was a chance to talk things over - what standards should a draw framework ideally have? 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?

So in the mid run, you missed a chance to collaboratively instead of competitively develop a framework. Is there anything wrong with that? Not as such - there's always pain vs. gain. FG profits from having both JSBSim and YaSim, as they do manifestly different things. But is FG better because we have three (or four?) different standards to load Nasal modules? I doubt it.

In the end, I feel I've missed a chance to have a positive collaborative experience with something FG-related that's not Shuttle.

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.

I dunno - when I implemented volcanoes, there was a long discussion preceding how this is best be done and where resides what. When I needed more environment computations, I wasn't exactly happy with how the ones we already have were done - but I just added mine to that framework and used the existing style to keep things simple. Yes, often things aren't coded 'my way' - but I can usually deal with things not being my way, adapt and extend what is there.

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.

That's in my view a pretty bad thing (TM). Whether you do not provide a draw routine I provide or not is in comparison a pointless question.

End of rant.

It's done, I've expressed my unhappiness about the process this has happened - do with that whatever you like.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas.draw library merged to FGDATA

Postby Hooray » Tue Mar 10, 2020 2:05 pm

To be honest, I can fully relate to Thorstens point of view - but I don't think this is a fair summary of the events, also like I said, the approaches/nature of the code in question is very different.
We kinda had the same discussion about the shuttle draw helpers in the context of rleibner's original work.
Also, to be fair, this isn't exactly a first either - for instance, the shuttle's trajectory map could have also been implemented using the existing Canvas "Map" API, i.e. by adding to it, rather than coding it from scratch (the corresponding postings can still be found on the forum, so I fully get your point for not getting involved there).

Likewise, there are people now doing their own NDs, rather than adding to the existing ND stuff, and other people creating their own mapping frameworks, rather than using "MapStructure".

So I think the shuttle, or you (Thorsten), have been on both ends of this, so you can certainly also relate to using/not using a certain approach.

Like I said, as far as I remember, the shuttle helpers were fairly generic/simple, and strictly procedural - i.e. there was no support for customizing things, or support for IoC by passing an options hash and/or delegates into the corresponding function - also, to be fair, the MapStructure 2D drawing helpers even predate the shuttle by several years...

So all of us have experience being on both sides of the dilemma - especially the Extra500 contains a ton of great code, that is hardly reusable, and some of it was written from scratch, despite existing code having been around for years.

To be honest, I don't think there is any real "solution" available - other than encouraging people to use a library/framework-centric approach so that they're able to factor out useful stuff, so that it can be eventually added to the base package.

Other than that, the real problem lies elsewhere, and isn't specific to the Canvas system, like you said: it's Nasal and its "free-form-nature" that supports a plethora of pathways to get functionality added, and more often than not, people are not enormously experienced contributors, so that the whole notion of "inversion-of-control", "injection of heuristics", "passing delegates" or "options hashes", or doing proper OOP, let alone "MVC" is obviously very far-fetched ...

This is something where Emesary could help people implement generic solutions that can be easily reused, unfortunately that's another undocumented thing, and people will need a strong programming background to see the merits of pursuing that route. I believe, so far, Stuart is the only one (except for Richard himself obviously) to use Emesary for some actual project, i.e. the FG1000.

In my eyes, by and large this is primarily a way of how we've come to expose the Canvas system via Nasal to scripting space, it would have been far better to use encourage a framework-centric paradigm, where higher level drawing primitives can be created on top of lower level primitives (think canvas elements like path, text, image, group), with well-defined I/O properties to manipulate those.

This is how the existing Canvas.Widget system works, i.e. the one implemented by TheTom back in 2012 - and it supports inheritance, too - analogous to how effects can inherit from each other - that way, we could create a dedicated canvas element named "HSI" that would inherit from "compass rose", which would in turn inherit from a lower level draw framework.

This kind of setup would then also make it trivial to get rid of the legacy 2D panels code, at the mere cost of writing a parser to interpret/map 2D panels to canvas gauges (analogous to how pui2canvas works).

Once we encourage an element-based extension mechanism, where new drawing primitives can be prototyped/implemented and registered in scripting space, we will also see more work flowing back in a generic form, i.e. without being specific to certain aircraft/avionics. This is something where we as a project failed, because nobody could foresee the impact of the Canvas system back in 2012.

The implication of this, as well as the major benefits of pursuing such a decoupled approach, are magnified by looking at multi-instance use-cases, i.e. those having to use multiple instances of a single instruments/screen (device), but also multiple inter-linked fgfs instances (think multiplayer/multi-pilot, but also LinuxTag/FSWeekend).

What we're currently doing doesn't scale at all - besides, we don't currently provide a good mechanism to easily wrap/re-implement performance-critical functionality in native code/C++ - and that, too, would change immediately once all future Canvas MFDs/avionics would be implement as stacked elements implemented in scripting space, using lower-level elements implemented in native code. Whenever a certain scripted element (think HSI or PFD) should become an issue, it could be easily re-implemented in native code, without people having to update their code.

This is a long-standing issue, and it has been repeatedly discussed here and on the mailing list - so, what's needed is allowing frameworks and elements to be scripted in Nasal, so that they can be registered as scripted canvas elements, with their own well-defined I/O properties that are "element" specific (think hsi-heading, vor-obs, station-station etc).

At that point, it would also become a piece of cake to inter-link multiple fgfs instances, regardless of the purpose (multiplayer/dual-pilot or multi-instance setups showing different screens)

http://wiki.flightgear.org/Canvas_Devel ... FlightGear
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: 11896
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby wkitty42 » 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...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6551
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: canvas.draw library merged to FGDATA

Postby Thorsten » Tue Mar 10, 2020 7:01 pm

Also, to be fair, this isn't exactly a first either - for instance, the shuttle's trajectory map could have also been implemented using the existing Canvas "Map" API,


Do you see a difference between implementing a single use case n times differently aircraft side in n different craft (that's what you are talking about) and implementing n different frameworks trying to solve the same thing FG-side (that's what I am talking about)?

Because for me these are very different things - the former is at worst extra work for the aircraft developer, the latter bloats FG and makes it progressively difficult to maintain.

there's no clear list of what's available that is easily accessible and up-to-date...


As an aircraft developer, you can look around, write yourself or simply ask - people never have to install your craft, so it doesn't really matter.

If you develop FG, people are forced to install whatever you code - which is why it generally is a good idea to announce what you're about to do on the mailing list so that people can say their piece. It's how the project is supposed to self-coordinate.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas.draw library merged to FGDATA

Postby Hooray » Tue Mar 10, 2020 7:49 pm

Of course I do see the difference, but the utility itself would be useful regardless of the shuttle, i.e. for any "satellites", including not just other spacecraft.
So there is no point in arguing about it, I can also relate to the workload involved in integrating things into an existing framework vs. coding something from scratch, so there's that, too.
And that's exactly what's been happening here, too - but like jsb said, this is basically rleibner's original work, committed to fgdata - so it would make more sense to update the corresponding addons eventually.

It's also higher level than your shuttle related helpers, i.e. both approaches could probably augment each other to some degree.
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: 11896
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.draw library merged to FGDATA

Postby jsb » Tue Mar 10, 2020 8:31 pm

Hooray wrote in Tue Mar 10, 2020 12:30 pm:Thorsten kinda hit the nail on the head when he said, that there is unfortunately a growing tendency to re-invent the wheel, often at the aircraft-level, rather than the library/framework-level - so this effort is certainly one step into the right direction.
So it would be good to have a maintainer to review existing code and see how things could be better reused, by generalizing useful code and extracting it into a dedicated framework/library.

1) Agreed, that is why I spent time to port useful stuff from some addons into a lib that ships with FlightGear (to be more precise: will ship in FGDATA with the next release)
2) True, but it would be even better if people(tm) a) check if there is a suitable framework matching there needs b) if not, develop their stuff in a way that allows generic parts to be included as lib in FGDATA.

Whenever I stumble upon nice code in some aircraft (which happens only by chance once in a while), I think about if this can be included in any of the existing libs and bring it there.
What I cannot do is make people use the libs and frameworks, e.g. migrate their planes (remove duplicate code, use the libs) - I can inform about what is available and that it would be "a nice thing"(tm) to use it but thats it.
jsb
 
Posts: 265
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 8:42 pm

Hooray wrote in Tue Mar 10, 2020 7:49 pm:- but like jsb said, this is basically rleibner's original work, committed to fgdata - so it would make more sense to update the corresponding addons eventually.

I already planed to contact him and ask him if it would be ok for him to have his addons updated - we cannot do that without asking him first.
jsb
 
Posts: 265
Joined: Sat Oct 25, 2014 8:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests