Board index FlightGear Development Canvas

Canvas G1000

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 G1000

Postby Hooray » Sat Feb 10, 2018 9:17 pm

Stuart is maintaining a list of completed and missing MFD pages, including their SVG files: http://wiki.flightgear.org/FG1000#Page_Status

For the corresponding SVG artwork, see: https://sourceforge.net/p/flightgear/fg ... /MFDPages/

If you'd like to help with any of the still missing pages, you can use one if the existing pages and use that as template.

There is also a Perl script to create the corresponding Nasal boilerplate to hook up the SVG to the MFD/Emesary 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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Sat Feb 10, 2018 9:43 pm

Hi Guys,

Thanks very much for the continued work guys. Much appreciated.

I think for the PFD, just having a single SVG file will be sufficient. If you've got that and some snippets of Canvas code indicating how it should be animated, I can do the rest of the work to integrated it.

More generally, I've just finished converting www2's GDU models to work with the MFD. So you can now add the MFD to an aircraft, and have it mirrored to a GUI if you wish. The wiki page has details of how to do this - I've put some effort into making it as straightforward as possible.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1467
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Sat Feb 10, 2018 9:49 pm

The wiki page has details of how to do this - I've put some effort into making it as straightforward as possible.

For the Nasal code setting up everything, I would still suggest to use named function call arguments in the form of:

Code: Select all
fg1000system.addPFD(device:1);
fg1000system.addMFD(device:2);

fg1000system.displayGUI(device:1, scale:0.5);


the .getInstance helper could also be named getOrCreateInstance(), because that's basically what it is doing, isn't it ?

and like I said in my PM, I would definitely suggest versioning the fgcommand layer that encapsulates Emesary notifications - so that interlinked fgfs instances (dual-control, multi-instance setups etc) can detect mismatching fg/fg1000 versions.

for the fgcommand layer, we could also use OBJECT.METHOD notification - even though I do think that making the class/name of the instrument part of the fgcommand arg vector would make sense so that the correspondign logic can be moved to the 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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby www2 » Sat Feb 10, 2018 10:18 pm

@stuart
I can do this.
But my idea is more for adding other flightdecs from garmin on an later moment that reuse the widgets. E.g. the G500/600 series of flightdecks.
www2
 
Posts: 242
Joined: Thu Apr 16, 2009 1:58 pm

Re: Canvas G1000

Postby Hooray » Sun Feb 11, 2018 12:46 pm

In theory, that sounds like a good idea - in practice, the FG1000 structure isn't currently suited for that, i.e. would need a bit more refactoring - because it works primarily in terms of "pages" and not reusable "page elements". On technical grounds, I do agree that it would be a good idea to change that (over time) - especially if that means that other moving map developers could get involved in the FG1000 effort (think Farmin-like or the Avidyne Entegra R9/extra500 folks).
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Sun Feb 11, 2018 8:12 pm

@www2 - Hooray is correct - it will require a bit of refactoring to pull out the common elements to make a G500. However, that's definitely something I plan to do.

@Hooray - yes, saw your PM.
  • Do you have some reference/examples for named function call arguments. I couldn't find anything on the wiki, which suggests I'm not using quite the right words :) !
  • Renaming to getOrCreateInstance() is a good idea.
  • I need to think about the versioning a little more. We already have the minimum-version property, but that's not quite sufficient here.
  • Could you explain a little more about the OBJECT.METHOD notification as well? I may be being dum, or I may know it by some other name.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1467
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Sun Feb 11, 2018 8:17 pm

  • it's using the hash notation: http://wiki.flightgear.org/Using_Nasal_ ... _arguments
  • regarding versioning, keep in mind that in between fgfs releases, there may be major changes to the FG1000, so that it would be a good idea to track the FG1000 version separately - it's basically the same problem that "addons" and the "addon framework" have - breaking changes (those not backwards compatible) can only be made in a safe fashion if the corresponding sources (addons vs. aircraft) can request a certain version of the API, so that you can safely change settings using a new version of the fgcommand layer.
  • it's much simpler than it appears - fgcommands are just strings after all (I think std::map<std::string, SGCommand*> - thus, we can "emulate" the OBJECT.METHOD notation by simply using a corresponding string - which may make things more self-explanatory, then again I am not even sure if it's such a good idea ...
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby stuart » Sun Feb 11, 2018 8:27 pm

Hi Hooray,

Thanks - I thought it was more complicated and I had to do something special with a hash argument explicitly. Looks like an excellent idea - I'll modify the public interfaces.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1467
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Sun Feb 11, 2018 8:48 pm

Stuart wrote:it will require a bit of refactoring to pull out the common elements to make a G500. However, that's definitely something I plan to do.


While I do think that this would be a very interesting development direction for the FG1000 in the mid term, I am also convinced that establishing SVG as the primary mechanism for creating such elements will be really important, so that artwork contributors familiar with Inkscape/GIMP can get involved without having to know much/any Nasal at all. Otherwise, we will primarily see more and more copy & paste coding.

PS: The same mechanism can also be used to implement a simple form of function overloading: http://wiki.flightgear.org/Using_Nasal_ ... _call-time

Code: Select all

var set_temperature = func() {

}

set_temperature( fahrenheit_degrees: 112.00 );

set_temperature( degrees_celsisus: 144.00 );



the call using a certain symbol will not be nil, the other one will be nil
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas G1000

Postby Michat » Tue Feb 13, 2018 11:43 pm

https://ombx.io/w1uOG4k8 it contains last improvements of the skin.



https://ombx.io/P4U3Q30z it contains PFD things.



29.92 a lot of Gitubers
User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby www2 » Wed Feb 14, 2018 1:28 pm

@stuart and @Hooray

Oke. the EIS Display is a good candidate for this project.
www2
 
Posts: 242
Joined: Thu Apr 16, 2009 1:58 pm

Re: Canvas G1000

Postby Michat » Wed Feb 14, 2018 7:14 pm

User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby stuart » Thu Feb 15, 2018 8:12 pm

Hi Michat,

Thanks both for the updated SVG files and for reminding me of the zvk1000 project. I was aware of it, and indeed have had a number of discussions with the author about developing his work. However, I had completely forgotten it in the context of the PFD display.

I will take a look at the PFD SVG file that is used in the zvk1000 and see if it suitable.

Thanks,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1467
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Michat » Thu Feb 15, 2018 9:40 pm

Hope it helps, but not intercept with ww2 time-line. :roll:

I have some designs that might be useful if you want to provide help with some aesthetics of the canvas gadgets.


Image


Image

Thanks


29.92.
User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Canvas G1000

Postby Hooray » Thu Feb 15, 2018 9:54 pm

that looks good, it would definitely be useful if/when we have to get rid of PUI-based dialogs.
However, I don't think the ND dialog is currently part of fgdata ?
Anyway, it would be easy to make this available as an addon some day.

At least for now, I believe that the FG1000 deserves more attention - the way it is implemented, it could also have a massive impact on the way the ND code works - which is to say, that sooner or later the ND code is likely to be redone in my opinion - the mess it has become over time was mainly because it was never really shared on the forum during the prototyping/design phase, so that it would have had to be rewritten to do it properly.

These days, the MFD/Emesary approach used by the FG1000 is much more future-proof, probably in conjunction with a handful of extensions to the underlying Canvas/C++ code.

Personally, I would suggest not to expend too much time tinkering with the ND stuff, at least not in the current form.
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest