Board index FlightGear Development Canvas

Canvas MFD framework vs. EFB functionality

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 MFD framework vs. EFB functionality

Postby Hooray » Sun Sep 27, 2015 10:31 am

http://sourceforge.net/p/flightgear/mai ... /34493594/
Thorsten wrote:Using a general framework Richard has developed which in turn uses canvas routines, I find the work of generating all the screens merely tedious (positioning all items on-screen and linking them to properties is not very exciting work) but quite doable.


That is the MFD (=multi-function-display) code from the F15, right ?
I looked at it, it's using OOP to create a few abstraction layers for managing pages, items and for having a page controller.
Internally, most of this is mapped to "CanvasText" nodes (properties in the property tree), that are mapped to C++/OSG code using OSGText.

Originally, Tom came up with a few examples for the CDU use-case on airliners:


We were also hoping to generalize this functionality and come up with a Nasal-space framework for such scenarios, agnostic to certain aircraft/use-cases. But it seems that Richard's code has progressed much more in the meantime: http://wiki.flightgear.org/Canvas_MFD_Framework

So it would probably be good to update the wiki accordingly and add a link to the F15/SpaceShuttle code handling the MFD.

http://sourceforge.net/p/flightgear/mai ... /34493581/
Thorsten wrote:I *think* what Jens is describing is just a global _framework_ to store these kinds of documents which then each plane would use, so that you don't have to copy files into every aircraft directory separately - it'd then still be up to the user to acquire the _content_ in a legal way and put it there.

Without myself being much into airliner operation, to me this sounds a very useful idea. I think the best path forward is to get in touch with a few airliner maintainers who have used this kind of thing already, talk to them about a good interface/standard and then go ahead and do it - once it runs for 2-3 demo cases, others are going to adopt it.


Actually, the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.

But we do have code/prototypes doing EFB handling using Nasal & Canvas:
http://wiki.flightgear.org/Canvas_EFB_Framework
Image

More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: viewtopic.php?f=71&t=27499&p=258282#p258282
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas MFD framework vs. EFB functionality

Postby Richard » Tue Sep 29, 2015 11:55 pm

To elaborate on the MPCD (aka MFD) framework on the F-15.

The MPCD is made of pages, each page is an SVG group. Within this group are the elements for that page, for both static (labels etc) and dynamically updateable elements. I kept the design as simple as possible, as I wanted something that would let me lay out a page in inkscape and quickly connect it all up.

The MPCD_Device class is a container for all of the pages and provides the ability to load a page (MPCD_Page) from a group, together with handling button events.

An update method can be provided for each page if required. This page will be called at a regular rate (1/4 rate on the F-15). This update method is responsible for setting the svg derived elements to contain any updated values (or change colours, or move things).

There is a menu handling class (MPCD_MenuItem) that links a button id to a target page with a title. Each MPCD_Page has a list of menu items that the MPCD_device class uses to switch pages.

The HUD on the F-15 follows pretty much the same sort of approach (except there aren't any pages), so it has an SVG file that is loaded and the displayed elements are controlled in the nasal module. The HUD has a couple of neat things, firstly the convention of say objname and objname_clip where objname_clip is a clipping rectangle for objname. The other neat thing is the hud_data_provider which should be the interface between the properties and the values displayed on the HUD (although looking at it now it seems I forgot this design decision and directly reference properties in the update method).

If I were to implement approach plates in the EFB I'd probably use raster images provided via http and provide an http service within FG to do this, or to allow the EFB to use any other external web service. Other content for the EFB could be also provided as SVG via http.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Canvas MFD framework vs. EFB functionality

Postby Hooray » Sun Oct 04, 2015 6:11 pm

thanks for the update - have you considered generalizing the MFD code so that it can be moved to the Canvas namespace ($FG_ROOT/Nasal/canvas) ?
As you may have seen, we've been wanting to add a dedicated MFD module for quite a while now.
Obviously, that would have to satisfy a few requirements, namely being agnostic to the concrete use-case (type of aircraft, instrument), as well as support multiple instances, and multiple front-ends (screens, aka Canvas placements) using a source selector.

Once we have such a framework in place, it would make sense to revisit existing code (think PFD, ND, EICAS etc) and update the code accordingly, so that those instruments all share/interface the same MFD base-class.

The long-term idea being to prevent "copy & paste" programming, so that there is only a single script/module that needs to be updated, e.g. to support backward compatibility (versioning), but also to ensure that aircraft don't end up replicating/forking useful modules due to diverging priorities.

Regardless of your answer to this, it would make sense to move your last posting to the wiki and use it to document your code there.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas MFD framework vs. EFB functionality

Postby Richard » Sun Oct 18, 2015 4:22 pm

I've now refactored the MFD into a reusable element that is ready to go into fgdata - I haven't got commit access but I've asked Torsten...
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Canvas MFD framework vs. EFB functionality

Postby Hooray » Sun Oct 18, 2015 5:25 pm

thanks for the update, it may help to add a few docs/code snippets to the wiki article to ensure that this can be easily adopted/reused elsewhere.
I will also be sure to check out the code to see if we can possibly port the PFD/ND stuff to use your MFD framework.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest